Video: Introduction to Cynode Advisory and Assurance Services

RESOURCES

Where a Threat Shows Up Matters as Much as What It Is

Blogs
Date: Aug '26
Author: Cumhur Hatipoglu

Guidance on building a purpose-driven detection program that scales efficiently, produces reliable signal, and supports smarter security decisions.

Most conversations about detection focus on one question: did we catch it? That's the wrong question to stop at. A more useful one, and one we spend a lot of engineering time on, is quieter and less dramatic: given that we caught it, how much should we trust what we're looking at — and where should that trust come from?

Here's the idea in plain terms.

Every detection can be described along two, separate axes. One is surface — simply, where does the evidence live? Sign-in logs, endpoint process activity, email headers, cloud control-plane events. The other is vector — what is the behaviour actually trying to achieve? Credential theft, lateral movement, data exfiltration, and so on. These two things sound similar but answer different questions, and conflating them is one of the more common mistakes in detection engineering: assigning "where" based on the story a rule tells, rather than the log table it actually queries.

Once you separate them properly, something useful falls out. For most attacker behaviours, one surface produces meaningfully stronger evidence than any other. Credential theft is best evidenced in identity logs — that's where a token was actually misused, not where its downstream effects were later noticed. Ransomware activity is best evidenced at the endpoint, where encryption actually happens. Call that surface the primary one for that vector: not the only place the behaviour can appear, but the place where, if you see it, you should believe it fastest and trust it most.

That leaves a genuinely important second category: the same vector, observed on a different surface. This is not a lesser detection, and it is not noise. It's a precursor, a side-effect, or a related signal — real evidence that something is happening, just from a vantage point that isn't the strongest one available for that particular behaviour. Treat it with the same confidence as a primary-surface match, and you'll over-escalate routinely, training your team (or your customers) to stop trusting your urgency. Treat it as automatically less important and file it away, and you'll occasionally miss the early, quieter version of something that later becomes serious.

The right answer isn't a rule of thumb an analyst applies inconsistently at 2am. It's a structural one: a detection on its primary surface carries enough evidentiary weight to stand largely on its own. A detection on a secondary surface is real, and gets investigated with the same rigour — but it needs corroboration from elsewhere before it earns the same level of confidence. Not suppressed. Not downgraded to background noise. Held to a slightly different, and honestly, more accurate, bar.

It gets more interesting at the edges. A small number of attacker behaviours genuinely don't have one clean home. Disabling logging or tampering with security controls, for instance, can start on almost any surface — an endpoint, an identity system, a mail transport rule — and the useful question isn't "which surface owns this vector" but "where does this behaviour usually begin." That's still a primary surface, in the sense that matters for how much initial trust to extend, but it's a statistical judgment rather than an architectural given. Building a framework that can hold both kinds of vectors — cleanly surface-bound ones, and ones that genuinely aren't — without quietly breaking either model, turns out to be most of the actual engineering work.

Why does any of this matter outside of an engineering document? Because it's the difference between a detection programme that produces a lot of alerts and one that produces a small number of decisions you can actually trust. Alert fatigue isn't usually caused by too much telemetry. It's caused by treating every match as if it deserves the same amount of attention, which is a modelling failure disguised as a volume problem. The fix isn't a smarter dashboard or a louder AI summary sitting on top of the same undifferentiated pile of alerts. It's deciding, in advance and consistently, how much any given match is allowed to claim about itself — and building the rest of the investigation around proving or disproving that claim, rather than assuming it.

That's a simple idea. It also happens to be one of the load-bearing ones in how we think about detection at Cynode.

Get in touch to learn more: https://cynode.com/get-in-touch

RELATED RESOURCES

    Update cookies preferences