Omvia GraphWalker

Detection gap

For every technique we ran, what your monitoring should have seen

This is included with every engagement rather than sold separately. It is the honest opening move: you find out where you are blind whether or not you buy anything else.

Four states, and we will not collapse them

Each technique a run exercised comes back with its ATT&CK identifier, the log sources it depends on, and exactly one of these.

fired

Your monitoring saw it. Something matched, inside the window the technique ran in.

silent

Something watches this technique, your monitoring answered us, and nothing landed. A content problem in your estate.

unmonitored

Nothing watches this technique at all. A coverage hole — a different problem, usually owned by a different team.

unknown

We could not get a usable answer. This is not a finding and we will not round it into one.

Silent and unmonitored are different problems with different owners, and unknown is not a problem at all — it is a gap in our own measurement. Collapsing the three would let us hand you a clean bill of health for an estate nobody actually looked at. That is the single easiest way for a report like this to be worthless, so the states stay apart even when it makes the summary less flattering.

How we get the answer

What we can always tell you

What should have seen it. That comes from our own graph: the technique we ran, the detections known to watch it, and the log sources those depend on. It needs nothing from your side and it is available on every run.

What needs a connection

Whether anything actually fired. Our cloud cannot reach inside your network, by design — so this answer is fetched by your own agent, holding your own monitoring credential, and passed back. We never hold a key into your security operations.

Where that is not wired up, the report says so in the response itself rather than reporting quiet. Every way of failing to ask reads unknown, never silent.

Where nothing was watching, the report ships the content

Vendor-neutral Sigma, plus a search for the product you run. Ready to review — not ready to trust unread, and the file says which it is.

  • Each artifact carries a line stating whether that exact form has been watched firing on a real estate or is an unverified translation. Those two are never merged, and the label is in the file rather than only in the sales conversation.
  • It also tells you which index and source names to repoint. A search written for another estate will run perfectly in yours, match nothing, and look exactly like quiet.
  • The same rule is exported for more than one product, from one source. We are not using detection content to sell you a particular vendor's console.

We do not sell a detection catalogue. Content is generated from the techniques we actually ran against you, and a large library of unverified rules is easy to produce and worth very little. We also do not write your logging configuration: where a technique is silent because the telemetry is not being collected at all, we name the missing log source and stop there.

Most bundled content does not watch what we run

This is the finding the report exists to deliver, and on measurement it is not mostly a mapping problem. Against one vendor's own shipped ruleset, the overlap with the techniques our runs exercise was a single technique.

Which is the point rather than a complaint about that vendor. The question an engagement answers is what your estate saw, technique by technique. Where your monitoring already catches what we run, the report says so and we have nothing to sell you for it. Where it does not, you get content you can deploy — and once it is deployed, a response tier that can act on it.

On our own labs almost all of the proof that a technique is detectable came from content we wrote ourselves, because testing the loop end to end meant supplying whatever was not watching. That is a fact about our labs and not a claim about anyone's estate.