Who is accountable when analysts keep tuning toward infrastructure indicators instead of the underlying abuse technique?

Why Accountability Belongs Above the Detection Tuning Layer

The accountability question is not really about who wrote the rule or adjusted the dashboard. It is about who owns detection outcomes when the team optimises for brittle indicators instead of the attacker behaviour that actually matters. Security leadership owns that alignment because it sets priorities, approves coverage expectations, and decides whether the programme is measuring true abuse or just collecting noisy proxies. MITRE’s ATT&CK knowledge base is useful here because it helps teams anchor detections to tactics and techniques rather than to whatever indicator is easiest to automate.

When detection strategy drifts toward infrastructure indicators, the programme can look busy while missing the stable technique that reappears across campaigns. That creates a governance gap: analysts may be doing the work they were asked to do, but the wrong objectives were set above them. In practice, many security teams discover this only after repeated false confidence from indicator-driven tuning, rather than through intentional coverage design.

How Detection Strategy Drifts Away From Abuse Technique

Infrastructure indicators are often attractive because they are concrete: domains, IPs, URLs, and file hashes can be blocked, searched, and reported quickly. The problem is that these artefacts are usually disposable. A phishing operator can rotate them faster than most teams can maintain a durable blocklist, while the underlying abuse technique stays unchanged. If the control objective is defined too narrowly, analysts end up rewarding short term suppression over lasting detection value.

The better model is to ask what behaviour would still be visible if the infrastructure changed tomorrow. That means focusing on sequencing, interaction patterns, credential harvesting steps, suspicious redirect chains, callback behaviour, and post-delivery actions that reveal the abuse method itself. Detection engineering then becomes a matter of mapping those behaviours to observable telemetry, testing them against realistic intrusion paths, and reviewing whether each analytic still holds when one indicator is removed.

• Use infrastructure evidence as a clue, not the detection objective.
• Measure whether the analytic survives indicator rotation or domain changes.
• Review detections against adversary technique, not just campaign artifacts.
• Test whether an alert would still fire if the attacker reused the same method with different hosting.

This approach works best when telemetry is rich enough to show behaviour across email, endpoint, identity, and network layers. It breaks down when logging is too sparse to distinguish a one-off indicator from a repeatable technique, or when response teams treat every new IOC as a fresh detection problem.

When Indicator Tuning Helps and When It Misleads

Tighter indicator tuning often reduces noise, but it also increases the risk of building a programme around transient artefacts instead of durable abuse patterns. That tradeoff is real: teams need enough indicator use to block known bad activity, but not so much that detection quality is measured by the volume of suppressions. The consensus position is clear enough, even if execution is uneven: indicators are supporting evidence, not the end state of detection engineering.

Edge cases matter. In high-volume phishing campaigns, infrastructure indicators can be operationally valuable for immediate containment, especially when time is short and the campaign is widespread. But for accountability, that short term utility should not be confused with strategic success. The stronger the reliance on rotating infrastructure, the more likely it is that the real weakness lies in coverage design, not in the analyst team.

For that reason, leadership should distinguish between temporary blocking and durable detection maturity. If a control only performs while the attacker reuses obvious infrastructure, it is fragile by design. If it still works when the delivery layer changes, it is closer to the abuse technique that matters.

Risk and Threat Considerations

The material risk is control drift: organisations can believe they are improving detection while actually narrowing attention to disposable infrastructure artefacts. That creates blind spots against repeatable abuse techniques and can leave similar campaigns undetected once the hosting, domain, or payload changes.

Failure mechanism: Analysts optimise for the easiest observable indicator, while attackers preserve the same technique and swap infrastructure. The resulting feedback loop rewards fast blocking and suppressions, but does not build durable detection coverage for the behaviour that enables compromise.

Impact: The organisation accumulates false confidence, delays recognition of recurring abuse patterns, and increases the chance that a new campaign succeeds because the real detection gap was never addressed.

Practitioner Guidance

What to prioritise: Leadership should make the detection objective explicit: the team is accountable for recognising abusive technique, not simply for collecting and blocking indicators. If a rule cannot explain which behaviour it detects, it is probably too dependent on transient artefacts.

What to verify: Confirm that each high-value analytic still works when the attacker changes hosting, domain, or payload naming. The practical test is simple: if the indicator disappears but the abuse method remains, does the detection still surface a useful signal?

Practitioner takeaway: Accountability sits with the people who define what “good detection” means, because indicator-heavy tuning is a governance choice that can quietly trade resilience for short-lived convenience.

Related resources from NHI Mgmt Group

• When does an NHI become too risky to keep as-is?
• How should security teams reduce browser-based identity abuse when attackers keep changing infrastructure?
• When should teams simplify ReBAC policies instead of tuning infrastructure?
• Who is accountable when cryptocurrency infrastructure supports abuse networks?