Data teams know the argument by heart: do we write the checks ourselves, adopt a framework, or pay someone to run the whole thing? ThreatOps raises the same fork, only the asset is threat knowledge instead of tables. Where do requirements, indicators and hunt notes live, and who operates them? This comparison lays out three setups side by side, using the Ops Atlas entry on the discipline as the factual backbone, and finishes with a short rule for choosing.

What you are actually storing

Before picking tooling, list the objects. A working ThreatOps practice produces a handful of record types: a register of priority intelligence requirements, a source register with ratings, a set of indicators each carrying an expiry, hunt write-ups that end in an artefact, and a log of sharing decisions. That is not much volume. Thinking of it as a small, well-governed dataset with owners, lifecycles and quality gates keeps the conversation practical and stops anyone from shopping for a platform before the records exist.

Option one: a version-controlled repository

The Atlas says plainly that a small team may begin with a plain repository instead of a threat intelligence platform. Requirements go in one file, source ratings in another, indicators in a structured file with an expiry column, and each hunt gets a templated page. Pull requests act as the review step, and history gives you an audit trail for free.

• Strengths: near-zero cost, familiar workflow, easy to review, nothing to patch.
• Weaknesses: no automatic ingestion, no sharing in standard formats unless you script it, and indicator expiry only works if somebody runs the cleanup job.
• Fits when: one to three analysts, a few feeds, and sharing that is occasional rather than constant.

Option two: a threat intelligence platform

A platform stores indicators and context as linked objects, ingests feeds, and speaks the standard exchange formats, STIX 2.1 for the content and TAXII 2.1 for transport, both published by OASIS in 2021. The Atlas names two open-source examples, MISP and OpenCTI, noting that the latter has a Community Edition under Apache 2.0. Ingestion is where a platform earns its keep and where it can hurt you.

• Strengths: consistent data model, automated enrichment, real sharing and de-duplication.
• Weaknesses: someone must run it, tune it and clean it. A platform that ingests everything turns into a landfill with a search box.
• Fits when: several feeds and several consumers, regular exchange with peers, and at least one person whose job includes maintaining it.

One detail data engineers will appreciate: public intelligence servers are rate-limited. The Atlas notes that the ATT&CK TAXII server caps requests at fifty per ten minutes per address, so a naive polling loop from a shared network egress can lock out your whole team. Cache the catalogue locally and refresh it on a schedule.

Option three: managed hunting and intelligence

Here a provider runs the collection and the hunts and hands you findings. The Atlas treats this as the right answer in one specific case, covered below, and cautions that the word ThreatOps is also used as a product or team name by various vendors, so read the scope before assuming anything about a service.

• Strengths: expertise on day one, no internal hiring, predictable cost.
• Weaknesses: the findings still need an owner inside your organisation, your own context stays thin, and you inherit someone else’s definitions.
• Fits when: you have telemetry and someone to act on results but cannot staff the analysis.

Side by side

• Setup time: repository in an afternoon; platform in weeks; managed service depends on onboarding.
• Running cost: repository is mostly people time; platform adds infrastructure and upkeep; managed is a subscription.
• Quality control: repository relies on review habits; platform needs ingestion rules; managed relies on the provider’s reporting.
• Sharing: repository is manual; platform supports standard formats; managed varies.
• Lock-in: lowest for the repository, moderate for a platform, highest for managed.

How each one tends to fail

Every option has a signature failure, and knowing it in advance is cheaper than discovering it. The repository fails quietly: the expiry column stops being maintained, stale addresses linger, and eventually somebody blocks traffic on the strength of an entry from last year. The platform fails loudly, by growing. Each new feed adds objects nobody reviews until search results are mostly noise and analysts stop trusting them. The managed service fails politely. Reports arrive on schedule, nothing is wrong with them, and nothing changes in your environment because no internal person is accountable for acting.

The Atlas names a related anti-pattern worth printing on a card: more feeds does not mean more protection. Feed subscriptions are meant for flagging and alerting, per the guidance it quotes from the incident-response community, and not for automatic blocking. A feed that blocked a shared content delivery network in its worked runbook had to be reverted within minutes and demoted to alert-only within the hour.

The rule for choosing

The Atlas offers a decision tree that is refreshingly short. If you do not have ninety days of usable telemetry, fix the data first, because no intelligence tool compensates for a blind spot. If nobody owns acting on findings, buy managed hunting. If nobody has asked for intelligence, run a lean advisory model. Otherwise, build. Notice that tooling is the last consideration, not the first.

Data practitioners can add a corollary. Treat the telemetry the same way you treat a critical pipeline: define freshness, completeness and retention targets, then test them. A team that already validates its tables with a tool like expectation-based data validation is well placed to do the same for security logs, because a hunt is only as trustworthy as the records it searches. Likewise, if your orchestration is already tidy, bringing order to a chaotic data estate with an orchestrator gives you a ready home for the scheduled jobs that expire indicators and refresh catalogues.

A one-week trial you can run on any of them

1. Day one: write three requirements, each with one question, one fact and one decision.
2. Day two: list every source you already receive and give each a rating, even if rough.
3. Day three: add expiry dates to the indicators you hold, using fixed lifetimes by type.
4. Day four: pick one attacker behaviour and write the four-part hunt hypothesis for it.
5. Day five: run the hunt and record one of four outcomes: a detection request, a gap ticket, an escalation or a confirmed would-have-seen note.

At the end of the week you will know which pieces hurt. If the pain is in storing and finding records, evaluate a platform. If it is in analysis capacity, evaluate a managed service. If you barely noticed any pain, the repository is doing its job.

Measuring any of the three

Whatever you choose, judge it on outcomes. The Atlas describes a worked quarter with four useful ratios: coverage of requirements (five of six, so eighty-three percent), intelligence that led to an action (fourteen of forty, thirty-five percent), hunts that converted into an artefact (five of twelve, forty-two percent) and gaps closed (four of nine, forty-four percent). It also warns against vanity counts such as indicators ingested or reports published. A platform that doubles the intake while the conversion ratio stays flat has not improved anything.

A sensible migration path

Most teams do not pick once. They start with the repository, learn which records they truly use, and graduate to a platform when manual sharing becomes the bottleneck. Moving a clean, versioned dataset into a platform is easy. Moving a swamp is not. If you later hand hunting to a provider, your register of requirements and ratings becomes the brief that keeps the contract honest.

For definitions, the maturity ladder and the sharing guidance referenced here, consult the Atlas page that lays out the ThreatOps scope and tooling options. Read it with a pencil, decide which of the three setups matches your headcount, and write down the single record you will create first.