Concept

Detecting attacks you
have never seen.

Every rule and signature in your estate describes an attack somebody already survived. That is not a criticism of detection engineering, it is what the method is: recognise the known.

The question is what covers the rest, and the answer is not a better description of the unknown. It is to stop needing one.

The gap is structural, not a resourcing problem

Detection content has a lifecycle, and every stage of it has to complete before you are covered.

The technique is used

Against somebody, successfully. Nobody knows yet.

It is discovered

During an incident response, weeks or months later.

It is analysed and published

A write-up, a report, a conference talk.

Detection content is written

By a vendor, a community project, or your own team.

It reaches your estate

Tested, tuned for your environment, deployed.

You are covered

For that technique, in that form, until it changes.

Everything between the first step and the last is a window in which the technique works and nothing you own will notice. That window is not closed by hiring more detection engineers or subscribing to more feeds. It is inherent: you cannot describe what has not been described.

And the final step is conditional. Coverage lasts until the technique changes, the tooling is recompiled, or the estate shifts enough that the rule no longer matches. Then the cycle restarts.

The constraint an attacker cannot avoid

An attacker can change their tooling, their infrastructure, their payloads and their timing. They can compile something nobody has seen, buy infrastructure nobody has reported, and behave carefully enough that no individual action looks wrong.

What they cannot do is achieve anything without interacting with your estate. To move laterally they have to reach a machine they have not reached. To collect they have to open something they do not usually open. To persist they have to run something that was not running. To exfiltrate they have to talk to somewhere new.

Each of those changes the relationships in the estate, and that change is observable without knowing anything about what caused it. You do not have to recognise the attacker. You have to recognise that your environment stopped looking like itself.

Which is why novel attacks are not a special case

There is no separate capability here for unknown threats, no zero-day module, no heuristic layer that runs when the signatures come up empty. Knowing the attack was never part of the method, so an attack nobody has published is detected the same way as one everybody has.

The benchmark bears this out in a small way. SIET was evaluated against CICIDS2017 with no signatures, no threat feed and no knowledge of what the dataset contained, and detected every attack in it: brute force, denial of service, web attacks, infiltration, botnet command and control, port scanning and distributed denial of service. The same detector, with no tuning between classes. It did not know what any of them were.

The honest limit

An attack that changes no relationship is invisible to this. An implant that sits dormant and does nothing is not detected, because there is nothing to detect. It is also not yet an incident.

And if an estate is already compromised when SIET is switched on, that activity is learned as normal. The answer is not that this cannot happen; it is that the moment the attacker does something new, it is a departure from a baseline that includes their own presence. The beacon becomes normal. The next step does not.

What each approach requires to have existed first

This is the whole question, put plainly.

Approach	Needs to exist before it works	Covers novel technique?
Signatures	A sample, analysed and published	No
Detection rules	A description of the behaviour, written and deployed	No
Threat intelligence	Somebody having reported the infrastructure	No
Trained models	Training data, and retraining as the estate changes	Sometimes, if it resembles the training set
Structural detection	Your estate’s own recorded history	Yes

Test it against something it has never seen.

That is the only test that means anything here. Run SIET alongside your existing alerting, switch nothing off, and compare what each one raised.