The ticket arrives mid-morning: patients cannot load the scheduling portal’s images, a telehealth page hangs, and the helpdesk is relaying a dozen variations of “the website is broken.” Nothing was deployed. The network team finds that an address inside a shared content-delivery range had landed on a blocklist an hour earlier, courtesy of an automated feed. A single entry in a threat list has just interrupted legitimate work for hundreds of people. This post diagnoses that failure in the order a professional would: symptoms, cause, immediate response, structural fix. It addresses hospital information systems only and gives no clinical guidance.
The scenario is one of the anti-patterns written up in the Ops Atlas reference page on ThreatOps, where a worked runbook is offered for exactly this case. The discipline described there is a combined routine of intelligence and hunting, and one of its firmest positions is that feeds are meant to flag, not to block on their own.
Presenting symptoms
Typical signs: several unrelated sites degrade at once, the common thread being a shared infrastructure provider; firewall logs show denies against a handful of addresses with enormous legitimate traffic; and the denies began at the minute a feed was refreshed. If all three hold, suspect the feed before you suspect the application.
Root cause
The root cause is seldom the feed provider’s bad faith. It is usually a design choice on your side: the feed was wired directly to enforcement, with nothing in between to ask whether the indicator was safe to act on. The addresses of a content network are shared by thousands of tenants, so one tenant’s misbehaviour can taint an address that everyone else needs. A policy that blocks by address, with no allowlist check and no precision history for the feed, will eventually hit one.
The Atlas adds a deeper observation: the habit of subscribing to more feeds and assuming more protection is itself listed as an anti-pattern. A feed is an input to judgement, not a control.
Immediate response: revert first, discuss later
The worked runbook in the Atlas can be summarised as three clocks. Within minutes, the on-call person removes the block. The Atlas is clear that anyone on call has the authority to do this, with no committee, and that the intelligence lead then reviews the decision within an hour. Within the hour, the feed is demoted to alert-only so it can still report matches but cannot enforce anything. Within the month, the number of blocks that had to be reverted is recorded as a metric and watched.
Pause on that last item. Counting reversions is a quiet way of measuring the cost of automation. A feed with many reversions is telling you something even if every individual incident was small.
Structural fix: a gate before any block
Rather than relying on judgement in the heat of the moment, write the gate down. Per the Atlas, enforcement is allowed only when all of these hold:
- The source is rated in the top two reliability grades, and the specific item in the top two credibility grades.
- The feed has demonstrated precision of at least 0.9 across ninety days of measurement.
- The indicator does not appear on any allowlist, which is where shared infrastructure should be listed.
The second condition deserves attention because it requires data. In the Atlas’s worked quarter, one feed scored precision of fifteen percent, 18 true hits among 120 alerts. Against a gate of 0.9 it was never going to qualify, which left it on notification duty only, with its renewal now in question. Measurement turned an argument into a decision.
Why expiry belongs in the diagnosis
A second contributor to false blocks is age. The STIX specification makes the validity-end field optional, and an indicator without it has no stated lifetime. If the platform never expires entries, the address that was malicious in spring may be a fresh tenant’s in autumn. The Atlas proposes setting your own lifetimes by indicator type; its sample keeps a file hash for a year but an IP address for only a fortnight, because addresses get recycled far faster than file contents do.
A parallel from the clinic world
Readers from clinical backgrounds will recognise the pattern of staging: a coarse label is useful for routing, but not for final decisions without more information. The site publishes an overview of how a functional classification is used for context in cardiology, which is a reminder that a single category never tells the whole story, and the same applies to a single indicator. For a broader view of how engineering discipline and ecosystem thinking fit together, the post on a company’s approach to India’s digital domain through engineering discipline is a useful companion.
Verification after the fix
Do not close the incident the moment the portal loads again; a recovered page proves very little about whether the cause is gone, and a recurrence next month is far more likely if the review is skipped. Confirm four things: the offending feed is demoted and the change is recorded; the allowlist now contains the shared network ranges that matter to you; the revert count appears on the monthly dashboard; and the gate wording is in the written policy, not in someone’s memory. Then schedule a short review where the intelligence lead and the network owner agree on which, if any, feeds may ever enforce.
Prevention checklist
- No direct feed-to-enforcement path without a rating and a precision record.
- Allowlist maintained for shared infrastructure, reviewed quarterly.
- Every indicator carries an explicit end date.
- Reverts are cheap, fast and logged.
Conclusion
The diagnosis is almost always the same: automation was trusted before it was measured. The cure is a gate, an expiry rule and an easy way to undo mistakes. None of it needs new software. It needs a written policy and a person who owns it. Treat this as background reading on security operations; your own network team’s assessment decides what applies in your environment.
