Managed-service teams inherit a lot of quiet liabilities, and a threat feed wired into a firewall is one of the most common. Someone subscribed years ago, an integration was built, and since then it has either produced a daily avalanche of alerts nobody reads or, worse, silently dropped traffic for customers. This how-to takes one feed and walks it, step by step, from noisy input to a measured control, using the evidence-first approach that the Ops Atlas describes under the heading ThreatOps. Expect about two working days of effort for a single feed, and no new software.<\/p>\n
Write one line: who is accountable for this feed, and which decision does it support? If the answer is “nobody” and “none”, you have your first finding. In the Atlas, each intelligence activity traces back to a requirement that asks one thing, expects one answer and feeds one choice. A feed that supports no decision is an expense, nothing more. A sensible purpose reads something like: “flag outbound connections to hostile infrastructure so on-call staff can investigate.”<\/p>\n
Export every match the feed generated over thirty days, along with what happened next. You need three columns: the item, whether anyone acted, and whether the action found something real. Do not trust memory; the point of this step is to replace impressions with counts.<\/p>\n
Precision here is simple: confirmed useful hits divided by total hits. The Atlas works through a sample quarter where 18 of 120 matches proved useful, which is 15 percent, and its conclusion is that such a feed should only ever alert and may deserve cancelling. Treat your own figure with the same sobriety. Compare it against the threshold the Atlas uses for permitting automatic blocking, which is 0.9 sustained over ninety days. You will almost certainly fall short, and that is fine; it tells you where you stand.<\/p>\n
Score the provider with a letter for reliability, A at the top and F at the bottom, and score each class of item with a one-to-six credibility number. This is the grading scheme the Atlas credits to the incident-response community. A well-regarded provider’s new feed starts at A3: strong source, claim not yet confirmed by you. Update the numbers when the measured precision comes in. A letter that never changes is a label, not a rating.<\/p>\n
In the common sharing format, the expiry timestamp is optional. If it is blank there is no constraint at all, so old entries simply stay live. Decide lifetimes by indicator type. The Atlas offers a starter table: addresses expire in two weeks, links in a month, domains in two months and file fingerprints in a year. Implement them as a scheduled job and test it once by deliberately adding a dummy entry and confirming it vanishes on time.<\/p>\n
Decide in advance when an item may block traffic rather than merely alert. A defensible gate, borrowed from the Atlas example, has four conditions: the source is rated A or B, the item’s own credibility is a one or a two, a three-month precision measurement reaches 0.9 or better, and the item is absent from every allowlist. Anything that fails stays alert-only. Early maturity stages in the framework the Atlas cites assume alerting first, and blocking needs “careful consideration”, so you are in good company if your feed never graduates.<\/p>\n
Every block needs an undo path that anyone on call can use without asking permission, plus a review by the intelligence owner within an hour. Rehearse it. The Atlas gives a runbook for the classic failure: a feed lists an address that sits inside a shared content delivery network, customers suddenly cannot reach legitimate sites, and the team has to undo the block within minutes and demote the whole feed to alerting by the end of the hour. Track how many blocks you had to undo each month, a figure the Atlas recommends watching, and treat it as a candid score of the feed’s quality.<\/p>\n
Now use what you have. Pick a single behaviour, say unusual outbound connections from servers that normally talk to few destinations, and write a four-part hypothesis: actor, behaviour, location, evidence. Run it against your stored logs. Close it with one of the four outputs the Atlas lists, and record which. If your logs do not reach back far enough to answer, a gap ticket is the correct result, and a correct result is a success.<\/p>\n
After a month, report four things: how many of your requirements have answers, what fraction of the intelligence you processed led to an action, how many hunts produced an artefact, and how many gaps you closed. The Atlas sample quarter gives 83, 35, 42 and 44 percent. Do not report how many indicators you ingested or how many alerts fired; those numbers rise when things get worse.<\/p>\n
Finish with a plain verdict. If precision is poor and the feed supports no decision, cancel it and save the licence fee. If it is mediocre but useful for alerting, keep it alert-only and revisit in a quarter. If it clears the blocking gate for a narrow class of items, enable blocking for that class alone. Write the verdict and its date beside the owner’s name.<\/p>\n
Three snags show up in nearly every first attempt. The first is missing outcome data: nobody recorded whether an alert led anywhere, so step two yields blanks. Do not fabricate numbers; start recording from today and run the calculation after a full month. The second is the shared-address problem described above, where one entry points at infrastructure used by many innocent customers. Maintain an allowlist of such hosts and check new feed entries against it before any block takes effect. The third is a social one. Engineers who liked the feed will resist the verdict, so show them the numbers and invite them to challenge the method, not the conclusion.<\/p>\n
There is also a documentation trap. If the gate, the lifetimes and the reversal path live in one engineer’s head, the control disappears with that engineer. Put all three in a repository, with a short readme, and require a review for any change to them. The Atlas observes that small teams can manage their intelligence records this way without a dedicated platform.<\/p>\n
None of this is exotic for a support organisation. It is ordinary change discipline applied to security data, and it matches principles that teams already hold, such as the ones in core principles for dependable software delivery<\/a>: small changes, fast feedback, measured results. If your engineers come from infrastructure-as-code backgrounds, the reasoning in why operations engineers benefit from moving toward reliability practices<\/a> will feel familiar, because expiry jobs and block gates are just code in a repository with a reviewer.<\/p>\n A note on boundaries. This routine concerns the intelligence side of the house. Tuning production alert rules, running the round-the-clock queue and handling incidents belong to other disciplines in the Atlas’s scope map. Keep that distinction when you write service descriptions for clients, or expectations will drift.<\/p>\nWhat to read next<\/h2>\n