What follows is invented: a team of six runs a mid-sized online marketplace. Nobody in it exists, and the figures are there only to make a point, but each step matches a practice described in the Ops Atlas entry on ThreatOps. We will follow the team over one quarter and stop at the places where the evidence changed their minds.
Week one: a pile of subscriptions and no questions
The team lead opened a spreadsheet and counted what the company paid for: three threat feeds, a vendor newsletter and a membership in an industry sharing group. Nobody could say which of these had ever changed a decision. The lead’s first instinct was to buy a fourth feed. The analyst on the team asked a better question: what do we need to know that we currently do not?
That question is the entry point of the discipline. The Atlas calls the answers priority intelligence requirements and recommends keeping between five and eight alive at once. Each one is supposed to hold one question, one fact and one decision. The team wrote six, such as whether fake-account rings were targeting their seller onboarding and whether stolen-credential reuse was rising on the checkout login. Their growth-planning habits, much like those described in this blog’s piece on building a blueprint for digital growth, already favoured goals before gadgets, so the exercise felt natural.
Week three: grading what they already had
Next came a source register. Every feed and contact received a reliability letter and a credibility number using the FIRST-style scale the Atlas describes, A to F by 1 to 6. The industry sharing group, long trusted, got a high mark on reliability; its brand-new feed started a notch lower on credibility because it was new, which the Atlas illustrates with the A3 example. Nothing about this was dramatic, yet it changed behaviour: for the first time somebody could point at a rating and say why an item deserved attention or not.
The analyst also noticed that dozens of indicators in the shared repository had no end date. The Atlas explains that in the standard sharing format an expiry field is optional, so an item without one carries no constraint. The team adopted a table of lifetimes and let anything older drop out of active use.
Week five: the first ThreatOps hunt
Hunting began modestly. Using the actor, behaviour, location and evidence frame from the PEAK method that the Atlas cites, the analyst wrote down a hypothesis: if an intruder were using valid logins to reach internal tools remotely, we would see unusual sign-in patterns from the remote-access gateway. One behaviour, one place, one kind of evidence.
The result was neither a find nor a failure. The gateway logs covered only three weeks, not the ninety days the hypothesis needed. Rather than shrug, the analyst filed a gap ticket. The Atlas lists this as one of four legitimate ways a hunt can end, alongside a detection request, an escalation and a record that the behaviour would have been visible. Incomplete data is a finding about the environment, not a defeat.
Week seven: a lesson from a different industry
During a team review the lead shared a case the Atlas mentions: a security firm testifying before a US legislative committee in 2021 described how its own breach was discovered through an alert that an employee’s account had registered a second phone without the employee doing anything. The point the team took away was not about the firm. It was that a quiet, ordinary-looking account event was the thread that unravelled a serious compromise. They added a hunt on enrolment of new devices to their own login system.
Week nine: the feed that cried wolf
The team had switched one feed to automatic blocking after a sales call promised protection. Midway through the quarter, a partner’s image-hosting address was blocked and sellers complained. The runbook the Atlas describes was exactly what they needed: undo the block within minutes, return the feed to alert-only inside the hour, and count reversals monthly. The analyst then measured precision. Of 120 indicators the feed had produced and the team had been able to judge, only 18 had been right, which is fifteen percent. That is far under the ninety percent the Atlas sets as the bar for blocking, so the feed stayed on alert duty and went onto the list of subscriptions to cancel at renewal.
These numbers are invented, though the Atlas uses a worked quarter with the same fifteen percent figure to make the same argument. The learning stands either way: precision has to be measured before it is trusted.
Week ten: a surprising result in the lab
Curious about attacker overlap, the analyst ran a small exercise from the Atlas’s own material. Three well-known criminal groups, catalogued in the ATT&CK knowledge base, together use ninety-two distinct techniques, and only two of those appear in all three: use of valid accounts and use of external remote services. The analyst’s conclusion was practical. A defence built around one group’s playbook would miss most of what the others do, but the two shared behaviours were worth a permanent hunt. That brought the team back to account misuse and remote access, now with a clear reason.
The analyst also resisted a tempting dashboard. The Atlas warns that a coverage heat map is not a goal, noting in line with ATT&CK’s own guidance that tactics are not ordered steps and that not every technique should become a detection.
Week eleven: writing it down for newcomers
Before the quarter closed, the lead asked a colleague from the customer-support side, who had not taken part in any hunt, to repeat the sign-in hunt using only the written notes. It took her an afternoon and she reached the same conclusion about the log gap. That was the acceptance test in action, and it exposed two vague steps in the notes that the analyst then rewrote. Handing work to a stranger is the cheapest quality check a small team has.
Week twelve: reading the scoreboard
At quarter end the team computed its ratios. Five of the six questions had matching sources and coverage. Out of forty intelligence items reviewed, fourteen led to a concrete action. Twelve hunts had been run, five of which produced an artefact that the detection owner accepted. Nine data gaps had been logged and four closed. Those are the four kinds of ratio in the Atlas example, and the team’s own figures were different but of the same shape.
- Intelligence that produced an action mattered more than intelligence collected.
- A hunt that proved a negative counted as a success.
- A feed that failed its precision test lost its blocking rights.
- Every output had an owner and a date.
The lead read the numbers aloud and recommended the next quarter’s focus: fix the gateway log retention, repeat the sign-in hunt, and review which subscription earned its renewal. The team’s earlier reading on growing a product-led business with discipline had made the same argument about measuring outcomes instead of activity, only in a commercial setting.
What an analyst should take from the story
Three observations stand out. First, the team’s gains came from asking narrower questions rather than collecting more data. Second, every uncomfortable discovery, from the thin logs to the weak feed, was found by measuring something. Third, the work was small enough for six people with other duties. The Atlas suggests exactly this scale of entry, with a thirty-day start of an owner, five questions, a source register, expiry rules and membership of a sharing community.
If you want the underlying definitions, the maturity ladder and the timeline of frameworks, the Atlas article on ThreatOps lays them out in far more depth than a story can. Use it to test your own quarter against the same checkpoints, and be ready to be surprised by what the numbers say.
