Analysts closed the same nightly cryptomining alert by hand for fourteen months — why did nobody report it?

## The economics of the silent close Start by taking the analyst's side seriously. The nightly firing on the render farm takes about ninety seconds to close: recognise the rule, recognise the asset, stamp it, move on. Reporting it properly means working out who owns the rule — a detection team two org units away — writing up a case that explains the pattern, and then waiting. There is no acknowledgement, no ticket status they can see, and no expectation that anything will change. Ninety seconds beats that every night, and it beats it *every* night, which is how you get to fourteen months. Add the measurement layer. Tier-1 analysts are typically measured on queue depth, time-to-triage and time-to-close. Fast-closing a known misfire improves all three. Writing a detection-quality report improves none of them and consumes the time that would have. Nothing in the incentive structure asks for the behaviour that the detection programme depends on. Then add the organisational distance. The queue and the rule sit under different managers with different objectives, and the detection team is defending a false-positive budget of its own. A complaint arriving from outside that structure has no natural landing place. ## What it actually costs The cheap answer is the arithmetic: roughly 612 closures at ninety seconds is about fifteen hours. That number is real, and it is not the reason this matters. The reason it matters is **habituation**. Every close teaches the queue that this rule's output is meaningless. The rule exists to catch resource hijacking (`T1496`) — an intruder monetising your compute, which on a GPU estate is a natural target. When that finally happens on a render node, the alert arrives into a trained reflex: it looks like the six hundred before it, and the analyst closes it in ninety seconds. The rule fired. The telemetry worked. The detection still failed, and the failure is not in the rule at all — it is in the loop around it. A second, quieter cost: the coverage map still says this technique is covered. On paper, a working detection exists. In practice, its output has been neutralised by the people receiving it, and nobody has written that down anywhere. ## Fixing the route rather than the attitude **Make the disposition the report.** If closing already requires recording the deciding field and the asset group, the analyst has filed the report by closing the alert. No separate act of complaining exists to skip. This is the highest-leverage change and it is why the closure schema matters. **Aggregate automatically and route it.** A periodic rollup of closures grouped by rule, verdict and asset group would have surfaced this in the first month: one rule, one asset group, hundreds of identical verdicts. Nobody has to notice; the rollup notices. **Put an owner in the alert.** If the alert itself names who owns the rule, the route is one click rather than an archaeology exercise across org charts. **Return a receipt.** Tell the analysts what happened to the evidence they produced — including "the owner looked at it and the rule stays, here is why". A loop that swallows input without ever reporting back stops receiving input within weeks, and then you are back to silence with better forms. **Measure the contribution.** If detection-quality feedback is genuinely wanted from tier 1, it has to appear somewhere in how tier 1 is judged. Otherwise you are asking people to spend the time they are measured on doing something they are not measured on. ## Where your authority ends What happens to the rule after the evidence lands — narrowing the logic, scoping an exclusion, or dropping it entirely — is the rule owner's decision, made against obligations across the estate that the queue cannot see. The SOC's job is to make sure the decision is made explicitly, by a named person, on real evidence, rather than absorbed silently at ninety seconds a night for fourteen months.