Mission controllers do not trust a satellite because it was launched correctly. They trust it because a chain of checks keeps confirming it is where it should be, doing what it should do. Security teams are slowly adopting the same habit for their alerting logic, under a name that has started to circulate: DetectionOps. This walkthrough follows one imaginary rule from first idea to retirement, using the language of orbits and ground stations, so you can see why the steps come in the order they do.
Think of the story as a night shift at a small ground station. The people there watch dozens of signals, and every signal needs a rule that says “this looks wrong, wake someone.” DetectionOps simply asks that those rules be handled like flight software: written down, reviewed, tested before launch, watched in operation, and eventually decommissioned.
Step 1: Decide what you are actually trying to see
Before anyone writes a line of query syntax, the team writes down the behaviour they worry about. In orbital terms this is the mission requirement: “keep the craft inside this band, alert us if it drifts.” In DetectionOps the requirement comes from threat knowledge, such as a technique an attacker is known to use, rather than from whatever happens to be easy to search for in the logs.
A useful trick is to fill in a short template before touching the query. Write the goal, the technical context, the blind spots you already accept, the likely false alarms, and how you will prove the rule works. Teams that skip this page tend to build rules that fire constantly or never, because nobody agreed what success looked like. If you enjoy the basics of how objects hold a steady position above Earth, our earlier piece on how geostationary orbits work in simple terms makes a good companion: both topics are about stating a target precisely before measuring against it.
Step 2: Write the rule as code, in a repository
Now the rule gets written, and the important part is where it lives. Instead of being typed into a console and forgotten, it goes into a version-controlled repository, the way flight software would. Many teams use the open Sigma format for this, which describes a rule with a title, a description of which logs to look at, and a condition. Others stay with their platform’s native query language and simply store those files in the repository too; the Atlas treats that as a perfectly sound choice for a team running one monitoring platform.
The payoff is history. Six months later someone can ask why a rule changed and read the answer, instead of guessing. That is the same reason mission teams keep configuration logs for every command ever uplinked.
Step 3: Write the tests before you trust it
A rule that nobody has tested is a hope. The guidance summarised in the Ops Atlas entry on DetectionOps recommends at least two tests per rule: one sample that should trigger it and one harmless sample that should not. Tests written by looking at the rule tend to pass by construction, so write them from the behaviour you described in step 1, not from the query you just typed.
If you have decided to accept a blind spot, for example because a filter removes a noisy but legitimate source, record it as a test too, with an owner and an expiry date. This is like a launch checklist item marked “waived, reviewed again in thirty days.” The waiver is visible instead of buried in somebody’s memory.
Step 4: Have another person read it
Peer review is the ground-station equivalent of a second operator confirming a command before it goes up. A reviewer asks: does this match the requirement, does the test prove it, will it flood the queue? Survey figures cited in the Atlas suggest that many teams already use version control, fewer review every change, and fewer still run automated pipelines, so there is real room to improve at this step without buying anything.
Emergencies are allowed to be faster. The Atlas proposes that during an active campaign a rule may skip the staging period, but never the tests and never the review, with a second look within five working days. Speed changes the schedule, not the standards.
Step 5: Rehearse in shadow mode
Good teams do not switch a new rule straight to paging. They let it run silently for about a week, collecting what it would have alerted on, and then look at the results. Astronomers do something similar when they run a new instrument against a known star before pointing it at something unknown: the output is compared with what is already understood.
Shadow mode is where you find out that a rule which looked precise on paper fires every time a nightly maintenance job runs. Better to learn that on a quiet Tuesday than at three in the morning with a human being paged.
Step 6: Deploy automatically and measure in the field
When the rule is approved, a pipeline deploys it, ideally the moment the change is merged. Nobody should be pasting queries into production by hand, because a hand-edited console fix is erased by the next automated deploy and the rule quietly reverts to its old behaviour.
After launch the measuring begins. The Atlas works through a sample month for a library of 120 rules: one noisy rule produced forty alerts, of which six were genuinely malicious, so its precision was only fifteen percent, and each real catch cost roughly forty analyst minutes. Numbers like these are what let a team decide to tune, narrow, or retire a rule, instead of arguing from impressions. The same example shows why a heat map full of technique tags can read one hundred percent while only sixty percent of the priority behaviours were actually detected when emulated within ninety days. A tag is a label, not proof, much as a satellite listed in a catalogue is not proof that it is currently transmitting.
Step 7: Tune, and eventually retire
Each exclusion you add trades some noise for a small blind spot of its own. Keep a note of each trade and when it should be revisited. And when a technique falls out of use or a data source disappears, retire the rule openly, marking it deprecated rather than letting it linger. Orbital debris is what happens when old hardware is never formally closed out.
A short reality check on language: the Atlas is candid that the name DetectionOps is not an established standard. Documented uses trace back to one European public-sector project, while the underlying practice is widely written about as detection engineering and detection-as-code. Use whichever term your colleagues recognise, and focus on the habits.
Where to start tonight
- Export your existing rules into a repository and run a basic syntax check on every change.
- Pick the twenty noisiest rules and write one triggering and one harmless test for each.
- Run the next new rule in silent mode for a week before it is allowed to page anyone.
- Pick five high-priority behaviours and try to reproduce them in a lab to see whether the rules really fire.
If you want a second perspective on how a large mission measures itself in practice, our beginner’s guide to low Earth orbit covers the other end of the orbital spectrum, where checks happen far more often because things move fast. Alert logic benefits from that same rhythm: frequent small checks, written down, instead of one grand review each year.