Picture a web agency that loses a weekend to a compromised plugin on a client’s shop. Nothing is stolen, but the cleanup means restoring backups, rotating passwords and apologising to a client who expected better. On Monday the owner asks the question that matters: how could we have found out sooner, and who should have been looking? That question is the doorway into ThreatOps, and there are at least three sensible ways to walk through it. This article compares them honestly, the way you would compare themes or hosting plans before committing.
First, what we are choosing between
ThreatOps, in the words of the Ops Atlas published by xOps School, joins outside intelligence about attackers with purposeful searching inside your own systems. The Atlas is upfront that the label is not standardised and that vendors use it for unrelated products. What it proposes is an editorial choice: treat the two activities as one operation with owners, a rhythm and outputs.
The Atlas also supplies a decision tree for how to resource it. Paraphrased: if you lack roughly ninety days of useful logs, fix that before anything else; if nobody exists who would own and act on findings, pay for managed hunting; if there are no internal people who need intelligence, use a lean advisory model; otherwise build your own. Those branches give us our three contenders.
Option one: build ThreatOps in-house on plain files
The first path is the one a small studio can start tomorrow. Keep a repository with your priority questions, a source register, expiry rules and hunt notes. The Atlas explicitly says small teams may begin with a version-controlled repository rather than a dedicated platform.
What you gain: near-zero cost, total control and a paper trail that new colleagues can read. Every change has an author and a date, which suits teams already comfortable with version control for their code.
What you give up: automation. Matching indicators to your logs and sharing structured data with partners is slower by hand. Also, discipline lives in people, so if the person who maintains the repository leaves, the routine can stall.
Option two: add an intelligence platform
When volume grows, a threat intelligence platform stores indicators, relationships and reports, and speaks the standard exchange formats. The Atlas mentions two open options: MISP, currently in its 2.5 series, and OpenCTI, which is developed by a company called Filigran and has a community edition under the Apache 2.0 licence. Choosing between them is a matter of fit; the Atlas does not crown either.
What you gain: structured storage, de-duplication, built-in expiry handling and easier sharing through STIX and TAXII, both at version 2.1 since 2021.
What you give up: hosting effort, upgrades and a learning curve. A platform also tempts people into hoarding. The Atlas lists “indicators ingested” among the vanity numbers to avoid, and a shiny database makes that number grow effortlessly. The remedy is to tie every ingestion to a question on your list.
Option three: buy managed hunting
Some organisations have no one with time or appetite to hunt. A managed service brings specialists who search your logs on a schedule. The Atlas places this branch of the decision tree where the business has no owner for findings.
What you gain: skills on day one and coverage without hiring.
What you give up: context. A provider does not know your quirks, so your own team must still own the response to whatever is found. You should also insist on the outputs the Atlas describes for any hunt: a detection request, a data-gap ticket, an escalation or a written confirmation that the behaviour could not have slipped past. Without those, you are buying reports rather than results.
A side-by-side look
- Speed to start: plain files win, a managed service is close behind, a platform is slowest.
- Running cost: plain files are cheapest, platforms cost in time, managed hunting costs in fees.
- Depth of context: in-house paths know your estate best.
- Scale of sharing: platforms are strongest for structured exchange.
- Risk of stalling: highest for plain files with one maintainer.
For a website business, the in-house route maps well onto the way you already work. You track page changes in version control, review them in pull requests and measure results monthly. A small agency can run fortnightly hunts for one behaviour, such as unexpected administrator accounts or odd file changes on client servers, and write each result in the same notebook as its plugin audits.
Hunts a web team can run this month
Abstract advice gets easier when you picture a real hypothesis. The Atlas frames hunts through four prompts: who the actor is, what behaviour they would show, where it would appear, and what evidence would confirm it. For a team that manages client sites, three starter hypotheses come to mind.
- If an intruder used a stolen administrator login, we would see sign-ins from unfamiliar locations followed by new accounts being created.
- If a plugin were tampered with, we would see changed files outside any scheduled update window.
- If a hosting control panel were reached through remote access, we would see sessions at odd hours that match no team calendar.
Each one names a single behaviour and a place to look, and each ends with one of the four outputs. Run one per fortnight and you will have a dozen written results by the end of a quarter, plus an honest picture of which logs you wish you kept for longer.
The measuring stick that works for all three
Whichever route you pick, judge it by outcomes. The Atlas walks through a quarter in which a team scored itself on question coverage, the fraction of intelligence that led to action, the fraction of hunts that produced an accepted artefact, and the share of data gaps closed. In that example a feed with only fifteen percent precision stayed in alert-only mode and became a cancellation candidate. Blocking, says the Atlas, should be allowed only when a source has earned top reliability grades and measured precision of at least ninety percent over ninety days.
That rule is a handy tiebreaker for comparison shopping. Ask any vendor, platform or service how you would measure its precision against your own environment, and be wary of answers that start with the number of indicators they hold.
What about the website-owner angle?
Content management shops face a distinctive version of the problem. Your clients rarely know what to ask, so the visible pages become a proxy for trust. We have written before about how an About Us page earns credibility online, and how service pages that convert visitors into clients succeed when they are specific. Security routines earn the same trust in a quieter way: by being specific about what you watch for, how often, and what you do next.
When each path goes wrong
Every option has a typical failure story. Plain files go wrong when the notebook becomes a graveyard of unreviewed notes; the cure is a standing calendar slot and a rule that unanswered questions get retired at the quarterly review. Platforms go wrong when the data pours in faster than anyone can judge it; the cure is source ratings and expiry dates attached at the door. Managed services go wrong when findings land in an inbox with no owner; the cure is naming that owner before the contract is signed.
Notice what the cures share. None of them involves a new product. They are habits, and habits are exactly what the Atlas means when it calls the whole thing an operation rather than a purchase.
My recommendation, with a caveat
If you run a team of fewer than ten, begin with plain files and one fortnightly hunt. Move to a platform when sharing or volume forces it, not before. Reach for managed hunting only if you truly cannot assign an owner, and keep a person on your side accountable for acting on what it finds. The caveat is that this is a reading of one reference, not a universal rule; the maturity ladder in the Atlas runs from absent through consuming feeds to hunting programmes and intelligence-led operation, and where you sit on it matters more than which tool you choose.
To read the underlying reasoning and the full ladder, start with the Atlas entry on ThreatOps. Then pick one of the three paths, put a date in the calendar for your first hunt, and let the results tell you whether to change course.
