If you spend your days around models, pipelines and dashboards, the word ThreatOps probably sounds like one more label from a vendor slide. Fair enough. The term is slippery, and the Ops Atlas says so itself: no standards body defines it, and the practices underneath, gathering threat intelligence and hunting for intruders, are much older than the name. So let us do this the friendly way, with a short story about why the discipline exists and then a pocket glossary you can keep open in another tab.

The idea in one coffee-break

Imagine you run a service and you receive a steady drizzle of warnings: suspicious addresses, new scam tricks, reports of attackers abusing a particular login method. Some of it matters to you, most of it does not, and nobody has decided which is which. ThreatOps is the habit of deciding. Someone writes down what you need to learn, someone judges how far each source can be trusted, someone goes looking in your own systems for traces that the automatic alarms missed, and everything that gets learned ends up as a concrete action.

That last part is the heart of it. Intelligence that never changes a decision is trivia, and hunting that leaves no artefact behind is a hobby. The Atlas puts the two halves into a single operation on purpose, a choice its authors flag as theirs alone, not something the industry has agreed on.

Mini-glossary: eight terms, roughly in the order they turn up

Priority intelligence requirement (PIR)

A written question your organisation really needs answered, such as “which of our sign-in methods are attackers abusing this quarter?” The Atlas wants each one to carry a single question, a single fact and a single decision, and suggests keeping only five to eight alive at once. If your list has forty entries, it is a wish list, not a set of requirements.

Indicator of compromise (IOC)

A concrete trace, like an address, a domain or a file fingerprint, that may point to hostile activity. Indicators are easy to share and easy to match, which is why people love them, but they go stale quickly. The Atlas recommends setting an expiry yourself, because the standard data format for sharing treats an expiry date as optional. Its sample policy gives addresses two weeks and file fingerprints a year.

Tactic, technique and procedure (TTP)

The behaviour behind the trace: what an attacker tries to do and how. Behaviours are harder to change than addresses, so they make a sturdier thing to look for. The big public catalogue of attacker behaviour, MITRE ATT&CK, organises them, and its newest release adds two tactic names that break older mapping spreadsheets. Remember that a catalogue is a vocabulary, not a score to maximise.

Source rating

A small label that says how much to trust where something came from. The scheme the Atlas describes pairs a letter for the source’s track record with a number for how believable the individual item looks. A usually reliable provider’s brand-new report might be rated A3, meaning a strong source with a claim you have not yet confirmed.

Estimative language

The careful words analysts use for probability, such as “likely” or “unlikely,” paired with a separate confidence level. The Atlas notes that “likely” is commonly read as roughly sixty to ninety percent, and it gives one tidy rule: state the probability word or the confidence level, but not both in the same sentence, or the reader cannot tell which one is doing the talking.

Hunt

A deliberate search through your own records for activity that automated detection missed. Good hunts start from a hypothesis and stay narrow. The Atlas leans on the PEAK frame, which asks four things in order: Actor, Behaviour, Location and Evidence. Keep a hunt to a pair of behaviours at most, and repeat the exercise about every other week.

Traffic-light protocol (TLP)

A colour code stamped on shared information that says how far it may travel. Red is for named recipients, amber for the organisation and trusted partners, green for the wider community and clear for anyone. The current edition arrived in 2022.

Detection request

The handoff ticket. When a hunt validates something worth catching automatically, the finding becomes a request to whoever maintains the alert rules. Writing the rule itself is a different discipline, which the Atlas deliberately places outside ThreatOps.

Why a data-and-AI crowd might care

Notice how familiar this all feels. Ratings on sources are data quality scores. Expiry dates are time-to-live settings. A hunt with a hypothesis, a narrow scope and a repeatable result is basically an experiment. If you enjoy the discipline of using machine learning to sharpen business decisions, you already believe the core claim, which is that information earns its keep only when it alters a choice.

There is also a cautionary tale about automation in the Atlas. It rejects the idea that more feeds mean more protection and warns against wiring a feed straight into blocking. Its example rule lets a block happen only when the source is rated highly and the feed’s measured precision over ninety days is at least ninety percent, and it lets anyone on call undo a block immediately. It also shows a worked quarter where a feed’s real precision was fifteen percent, so the feed stayed in alert-only mode. Anyone who has watched a classifier misfire on production traffic will nod along.

Three myths a beginner should drop early

• “A hunt that finds nothing failed.” Not if your data was good enough to have caught the activity. That is a confident negative, and the Atlas counts it as a success. If the data was incomplete, you raise a gap ticket.
• “Sharing warnings is too risky.” The colour labels, pre-agreed classes of shareable material and the voluntary-sharing provisions in Europe’s NIS2 directive make sharing manageable.
• “Knowing which group did it tells us what happens next.” Attribution using public group data is background, not a forecast. In the Atlas’s lab exercise, three well-known groups used ninety-two distinct techniques between them and only two were common to all.

A starter path you can actually follow

The Atlas sketches a thirty-sixty-ninety-day plan, and the pace is gentle enough for a part-time owner. In the first month you name an owner, write five requirements, list your sources with ratings and expiry rules, and join a sharing community. In the second you add templates, run two hunts and agree on escalation rules, with the milestone being a first detection request accepted by the alert-rule maintainers. By day ninety you pick tooling if you need any, write a short strategic brief and renew or cancel one feed based on evidence.

If you are still deciding whether this belongs on your roadmap, there is a plain-spoken decision tree in the entry: when you cannot show three months of usable logs, repair that first; if nobody owns acting on findings, consider managed hunting; if nobody asked for intelligence, stay lean. If you are also mapping your own learning, a skills checklist for someone starting out in DevOps pairs naturally with these ideas, since the same engineers often end up running both.

A tiny worked example

To see the pieces fit, picture a team that runs an internal model-serving platform. Their requirement reads: which remote-access routes into our training cluster are attackers abusing right now? A provider they trust, rated A, publishes a note, and the team scores the specific claim at 3. They schedule a hunt for two odd behaviours around remote logins, find that their logs cover only part of the cluster, and file a gap ticket. Nothing dramatic happened, yet the team now knows exactly what they cannot see.

Keep the reference close

This post is a glossary, so it skips the maturity ladder, the case notes and the tooling advice. For those, read the full ThreatOps write-up in the Ops Atlas, then come back and test your understanding by drafting just one requirement of your own. Start with a question you could answer in a week, and see whether a hunt or a source rating helps you answer it.