Anyone who has watched a satellite pass overhead knows the feeling of looking at a tiny moving dot and wondering what is going on up there. Security teams get a similar feeling when they stare at logs: lots of small dots, very little context. ThreatOps is the habit of turning that scatter into a steady, repeatable routine, and since this blog spends most of its time on orbits and spacecraft, we will explain it with a ground-station mindset instead of jargon.
The short version: ThreatOps combines two jobs that are often kept apart. One job is gathering and judging outside information about attackers. The other is going out and looking, on purpose, for signs of them inside your own systems. Done as one loop, the first job tells the second where to look, and the second feeds discoveries back to the first.
Think of ThreatOps as a ground station, not a telescope
A telescope collects whatever light happens to arrive. A ground station is different. It has a schedule, knows which satellite it expects, aims its dish at a precise part of the sky, and logs what it heard. If you have read our plain walk through geostationary orbit, you will remember that a satellite parked there appears fixed above one spot, so a dish can simply stay pointed at it. Low orbiters, in contrast, race across the sky in minutes and need careful tracking.
Threat work has both kinds of targets. Some adversary behaviour stays in one place for years and rewards patient, fixed attention. Other activity flashes by quickly and needs fast, well-prepared tracking. A ThreatOps routine decides ahead of time which is which, rather than swivelling the dish at every flicker.
Why a feed of warnings is not the same thing
It is tempting to believe that subscribing to a stream of threat data is the whole job. The Ops Atlas, a reference collection maintained by xOps School, makes the point explicitly in its entry on ThreatOps: a subscription to indicators is an input, not a programme. Quoting a group called FIRST, the Atlas notes that such feeds are meant for flagging and alerting rather than automatic blocking.
Space gives a gentle comparison. A list of every object tracked in orbit is useful, but nobody would call a printed catalogue a collision-avoidance operation. Somebody has to decide which objects matter for your spacecraft, how fresh the numbers are, and what to do when two paths come close.
Questions first, data second
The first practical step in the Atlas description is to write down priority intelligence requirements, usually shortened to PIRs. Think of them as the mission objectives for the ground station. The Atlas suggests keeping roughly five to eight active at a time and giving each one a single question, a single fact needed and a single decision it supports. A quarterly look back keeps the list honest.
A space hobbyist might phrase their own equivalent like this:
- Which of the passes this week can I realistically record from my balcony?
- Is the tracking data I downloaded recent enough to trust for tonight?
- Do I need to change my antenna plan before the next clear sky?
Notice that each line asks one thing and leads to one choice. A vague wish such as “learn everything about satellites” produces a pile of notes and no decisions. The Atlas warns about the same trap in its own field, where a broad request like “everything about ransomware” has to be chopped into narrow questions before anyone can answer it.
Trust has a grade
Not all information deserves equal weight. Amateur trackers know that orbital elements get stale: a number fetched last week for a low orbiter can be hopelessly off by now. Security teams handle this with a rating on every source. The Atlas describes the FIRST approach of pairing a reliability letter from A to F with a credibility number from 1 to 6, so a brand-new feed from an otherwise trusted provider might begin at A3 rather than a flat “good”.
The same idea shows up in how conclusions are phrased. Rather than vague hedging, analysts are encouraged to use standard probability words, where “likely” corresponds to a band of roughly sixty to ninety percent, and to state a confidence level separately. The Atlas adds a small rule worth borrowing for any forecast: do not put both in the same sentence, because the reader will not know which one to believe.
Old data must expire
Here is where the orbit analogy really pays off. A satellite position is only valid for a short window; after that it is wrong. Indicators of compromise, such as an address or a file fingerprint, behave similarly. The Atlas points out that the common sharing format, STIX, lets you set a “valid until” date but does not require it, so without one an indicator simply has no constraint and may sit around forever.
Its example policy sets different lifetimes by type: fourteen days for network addresses, thirty for web links, sixty for domain names and a full year for file hashes. You do not need to copy those numbers, but the principle travels well. Give every piece of information a use-by date before it enters the system.
Looking on purpose: the hunt
Now the second half. A hunt starts with a guess, written as a hypothesis: “if an intruder were using stolen credentials to get in remotely, we would see this pattern in these logs”. The Atlas leans on a frame from Splunk called PEAK, where hunts are described through Actor, Behavior, Location and Evidence. One or two behaviours per hunt, repeated about every fortnight, keeps it manageable.
Every hunt must end in something tangible: a request for a new detection, a ticket describing a gap in data, an escalation, or a note recording that you would have seen the behaviour had it occurred. The last one surprises people. A hunt that finds nothing can still succeed if the data was good enough to prove the negative. Compare this with a night of sky watching when the satellite you wanted never appeared; if your equipment was working and the pass was real, “no signal” is a legitimate result and worth writing down. If the dish was not even pointed correctly, that is a gap to fix, not a success.
The Atlas also offers a neat quality test: someone who did not take part should be able to rerun the hunt from your notes and get the same answer. Anything else is a story, not a record.
What stays out of the circle
It helps to know what ThreatOps does not try to do. According to the Atlas, round-the-clock alert watching belongs to the security operations centre, building the production alert rules belongs to a detection discipline, handling live incidents belongs to response, and ranking software weaknesses belongs to vulnerability work. The handoff rule is simple: a hunt finding that holds up becomes a request to the detection team.
Picture a launch campaign. The tracking crew, the flight controllers and the payload scientists all work with the same spacecraft, yet nobody expects the tracking crew to command a manoeuvre. Clear edges make each group better at its own part.
A tale of one long stay
Why bother with patient looking? The Atlas cites a joint advisory from US agencies in early 2024 about a state-linked group, noting that conventional indicators were “generally lacking” and that footholds had been kept for at least five years in some places. When a visitor leaves no obvious fingerprints, a sweep of known bad addresses proves very little. Only behavioural questions get you anywhere.
The Atlas also relays figures from a 2026 industry report, saying the global median time that intruders stayed unnoticed rose to fourteen days from eleven, and was far longer for espionage-style cases. Treat those as the Atlas reports them, and remember they are about security, not space, but the lesson is familiar to anyone who tracks slow drift in an orbit: small changes that nobody checks for accumulate.
Measuring without fooling yourself
The entry includes a worked quarter with ratios such as how many requirements had matching coverage and how many hunts resulted in a new detection. It also lists vanity numbers to avoid: how many indicators were ingested, how many reports were written, how many hunts were started. They are easy to inflate. A ground station that boasts about hours of recording but never decodes a signal is not performing well.
If you take one measurement from this, take the share of effort that ended in an action, because action is the point of intelligence.
Starting small, the way hobbyists do
Nobody builds a full tracking array on day one. The Atlas outlines a thirty-sixty-ninety style start: name an owner and five requirements, keep a simple register of sources, add expiry dates and join a sharing community in the first month; run two hunts and agree escalation rules in the second; choose tooling and review whether any feed earns its renewal in the third. Small teams are told they may start with a version-controlled folder of notes rather than a dedicated platform.
That advice matches the best habit in amateur astronomy: keep a logbook. If you also want to understand why orbit height changes how often you can look at something, our beginner article on low Earth orbit pairs nicely with the idea of fast-passing targets that need preparation.
The takeaway
ThreatOps, as described in the Atlas, is not a gadget and not a subscription. It is a loop with questions at the front, graded sources in the middle, patient looking on a schedule, and an artefact at the end of every round. Keep that picture in mind the next time a wall of dots tempts you into reacting to everything at once.