Detection ohne Signaturen: vier Engines, vier Annahmen

8 Min. Lesezeit

Signaturbasierte Detection erkennt 2026 nur noch die Angriffe, die ein Angreifer ohnehin schon hinterlassen wollte. Behavior-Analytics, ML-Anomalie-Modelle und LLM-Reasoning füllen die Lücke, sie sind aber keine drei Varianten desselben Werkzeugs. Wer sie als gleiche Klasse einkauft, baut ein SOC, das im echten Vorfall ratlos bleibt.

Das Wichtigste in Kürze

Signaturen bleiben Pflicht, nicht Lösung. Sie fangen das Rauschen, das jedes SOC vom Tisch braucht. Für gezielte Angriffe sind sie der falsche Layer.
Behavior-Analytics braucht Inventar. Wer kein Baseline-Verständnis seiner User und Maschinen hat, bekommt aus Behavior-Engines vor allem Lärm.
LLM-Reasoning ist die teuerste Klasse. Sie liefert die besten Erklärungen, sie ist im 24/7-Betrieb noch nicht günstig. Für gezielte Untersuchungen schon, für blanket Detection noch nicht.

Verwandt:KI-getriebene Bedrohungsanalyse für deutsche SOCs / NIS2 trifft CLOUD Act

Was eine Detection-Engine 2026 wirklich leistet

Was ist eine Detection-Engine? Eine Detection-Engine ist die Komponente in einem SOC- oder EDR-Stack, die aus Rohdaten eine Aussage macht: hier passiert etwas, das jemand anschauen muss. Sie wertet Logs, Telemetrie und Network-Flows aus, vergleicht sie mit Mustern oder Modellen und liefert Alerts. Die Engine entscheidet damit, was als Vorfall sichtbar wird und was im Hintergrund verschwindet.

Die Detection-Landschaft hat sich in den letzten drei Jahren aufgefächert. Wo bis 2022 IDS und EDR die Felder dominierten, stehen 2026 vier methodisch unterschiedliche Engines nebeneinander: Signaturen, Behavior-Analytics, ML-Anomalie und LLM-Reasoning. Sie kommen aus unterschiedlichen Welten, sie kosten unterschiedlich, sie liefern unterschiedliche Ergebnisse im echten Incident.

Die Diskussion in deutschen SOCs läuft seit zwei Jahren um die Frage, welche dieser Engines die „richtige“ ist. Die Antwort ist nicht eine Engine, es ist eine bewusste Schichtung. Wer das ignoriert, kauft Werkzeuge, die sich gegenseitig überdecken oder die offene Lücken hinterlassen, die niemand benennt.

Vier Engines, vier Annahmen, vier Schwächen

Engine	Stärke	Blinde Stelle	Voraussetzung
Signatur	Schnell, billig, deterministisch. Massen-Malware ohne Aufwand erkannt.	Living-off-the-Land, Zero-Days, gezielte Angreifer mit Custom-Tooling.	Aktuelle Threat-Intel-Feeds, gepflegte YARA-Regeln.
Behavior-Analytics	Erkennt anomale Sequenzen wie ungewöhnliches Lateral Movement oder Service-Account-Missbrauch.	False Positives bei lebenden Umgebungen ohne sauberes Inventar.	User- und Asset-Inventar, sechs bis acht Wochen Baseline-Lernphase.
ML-Anomalie	Findet statistisch ungewöhnliche Muster über große Datenmengen, auch ohne Threat-Intel.	Schwer erklärbar, schwer zu kalibrieren, Drift bei jedem Umbau der Infrastruktur.	Stabile Datenpipeline, ML-Engineer im Team oder im Managed-Service.
LLM-Reasoning	Kontext-reiche Erklärung von Alarmen, Vorschläge für nächsten Untersuchungsschritt.	Kosten pro Alert sind nicht trivial, Halluzinationsrisiko bei Edge-Cases.	Saubere Log-Aggregation, deutsche oder europäische Inferenz-Region.

Quelle: Eigene Auswertung von DACH-SOC-Konfigurationen Stand Mai 2026.

Die Tabelle ist kein Ranking. Sie zeigt, dass jede der vier Engines ein anderes Problem löst und gleichzeitig ein anderes Problem hinterlässt. Wer nur signaturbasiert arbeitet, hat ein SOC, das gezielte Angriffe nicht sieht. Wer nur LLM-Reasoning kauft, hat eine teure Engine ohne Rohdaten-Disziplin.

Welche Angriffsszenarien welche Engine wirklich braucht

Drei Beispiele aus dem Vorfall-Alltag der letzten Quartale machen die Schichtung greifbar.

Erstens, eine Massen-Phishing-Welle mit bekannter Malware-Familie. Die Signatur-Engine erkennt die Attachments innerhalb von Minuten, weil sie in der Threat-Intel-Datenbank sind. Eine Behavior-Engine könnte den Versuch erkennen, sie ist hier aber das langsamere Werkzeug. Eine LLM-Engine würde die Erkennung erklären, ohne sie zu beschleunigen. Konsequenz: Signaturen sind hier richtig, alles andere wäre Overkill.

Zweitens, ein gezielter Angreifer, der über kompromittierte Anmeldedaten in das Active Directory einsteigt und mit Bordmitteln lateral wandert. Keine Malware-Signatur greift. Behavior-Analytics ist hier die erste echte Chance, weil das Muster der Anmeldungen, der Service-Account-Verwendung und der Datei-Zugriffe von der Baseline abweicht. ML-Anomalie kann ergänzen. LLM-Reasoning hilft, die Alarme zu priorisieren und die nächsten Tracing-Schritte vorzuschlagen.

Drittens, ein subtiler Datenabfluss über Cloud-APIs, der sich als legitimer Backup-Job tarnt. Signaturen sehen nichts, weil keine Malware involviert ist. Behavior-Analytics sieht etwas, wenn das Backup-Volumen anomal ist, aber legitime Schwankungen können das Signal verstecken. ML-Anomalie über Cloud-API-Calls ist hier die Engine, die das Muster findet. LLM-Reasoning kann das Muster für das SOC verständlich machen.

Eine Detection-Strategie ohne klare Engine-Schichtung ist eine Liste von Lieferanten, kein Konzept. Im Audit reicht eine Liste nicht.

Was LLM-Reasoning in der DACH-Realität konkret kostet

0,80 €

kostet eine LLM-gestützte Analyse pro mittelgroßem Alert (etwa 5.000 Token Input, 1.500 Token Output) bei aktuellen Listenpreisen großer Anbieter. Bei 2.000 Alerts am Tag ergibt das einen sechsstelligen Jahresbetrag, bevor das Tooling drumherum dazu kommt.

Quelle: Eigene Auswertung Anbieter-Preise Stand Mai 2026.

Das ist nicht das Ende der LLM-Engine im SOC, es ist eine Grenze für ihren Einsatz. Sinnvoll ist die LLM-Schicht 2026 vor allem in zwei Konstellationen: bei der Triage von hoch priorisierten Alarmen und bei der Untersuchung konkreter Incidents. Für die durchgehende Verarbeitung jedes Alarms ist sie aktuell zu teuer, das ändert sich mit den günstigeren Endpoint-Modellen vermutlich in der zweiten Hälfte 2026.

Wer eine LLM-Engine als blanket Detection anbietet, sollte den Preis pro Alert offen kommunizieren. Wer ihn nicht kennt, hat das Produkt nicht ehrlich kalkuliert.

Drei konkrete Schritte für die Detection-Strategie 2026

Schichtung im 90-Tage-Fenster

Tag 1 bis 30

Signatur-Schicht prüfen. Threat-Intel-Feeds, EDR-Standardregeln, Custom-YARA für die eigenen Workloads. Was ist aktuell, was läuft veraltet. Veraltete Feeds aktualisieren oder ablösen.

Tag 31 bis 60

Behavior-Schicht aufbauen. User- und Asset-Inventar konsolidieren, UEBA-Modul aktivieren, Baseline-Phase starten. Sechs bis acht Wochen sind realistisch, nicht zwei.

Tag 61 bis 90

LLM-Schicht für Triage definieren. Pro Severity-Level festlegen, ab wann eine LLM-Analyse läuft. Kosten-Cap pro Tag setzen, Region-Pinning auf EU sicherstellen.

Die ML-Anomalie-Schicht passt in 2026 noch in keine 90-Tage-Vorlage. Sie verlangt eine eigene Datenpipeline, sie verlangt einen ML-Engineer und sie verlangt eine Akzeptanz für False-Positive-Rauschen in der Lernphase. Wer sie ernst meint, plant ein Halbjahr, nicht ein Quartal.

Was sich gegenüber dem 2022er-SOC verändert hat

Drei Verschiebungen, die jedes SOC-Architektur-Update berücksichtigen sollte. Erstens: Signaturen sind nicht mehr der Hauptlayer, sondern der Hygiene-Layer. Sie bleiben Pflicht, sie sind nicht das Differenzierungs-Werkzeug. Zweitens: Behavior-Analytics ist 2026 für jedes ernsthafte SOC Standard, nicht Premium. Wer ohne läuft, akzeptiert eine Blindzone, die in NIS2-Audits sichtbar wird. Drittens: LLM-Reasoning ist die neue Premium-Klasse mit echter Wirkung, aber realistischen Grenzen.

Wer das in der Strategie nicht abbildet, kauft entweder zu viel auf einer Schicht oder zu wenig auf einer anderen. Die häufigste Fehlinvestition 2026 ist die eine teure XDR-Plattform, die alle vier Engines unter einem Dach verspricht und in der Praxis nur zwei davon ernsthaft umsetzt. Wer das prüft, prüft die Produkt-Roadmap des Anbieters, nicht den Marketing-Folder.

Häufige Fragen

Ist signaturbasierte Detection wirklich noch nötig, wenn Behavior und ML laufen?

Ja, aus zwei Gründen. Erstens fangen Signaturen das hohe Volumen an Standard-Angriffen, das Behavior- und ML-Engines mit Rauschen belasten würde. Zweitens sind sie deterministisch erklärbar, was im Audit und in der Compliance-Doku Gold wert ist. Ein SOC ohne Signatur-Layer hat höhere False-Positive-Raten in den anderen Layern und einen erschwerten Audit-Trail.

Wie lange dauert die Baseline-Phase einer UEBA-Engine wirklich?

Sechs bis acht Wochen in einer stabilen Umgebung, drei bis vier Monate in einer dynamischen. Wer in dieser Zeit eine Cloud-Migration, eine Office-365-Tenant-Verschmelzung oder eine größere AD-Umstellung fährt, sollte die Baseline-Phase verlängern, sonst lernt das Modell den Umbau und nicht die Normalität. Hersteller-Versprechen von „produktiv nach 14 Tagen“ gelten für vorgefertigte Use-Cases, nicht für eine ehrliche Baseline.

Können ML-Anomalie-Modelle erklären, warum sie einen Alarm geliefert haben?

Beschränkt. Klassische statistische Modelle wie Isolation Forest oder Autoencoder geben Anomalie-Scores aus, sie erklären ihre Entscheidung nicht im natürlichen Sprachfeld. Erklärbarkeitstechniken wie SHAP oder LIME helfen, sind aber im Live-Alert-Kontext schwer zu konsumieren. Praktisch übernehmen LLMs hier den Erklärungs-Teil, das ist die Aufgabe der LLM-Reasoning-Schicht.

Lohnt sich ein eigenes SIEM, wenn ein Managed-XDR-Anbieter alle Engines liefert?

Das hängt vom Reifegrad ab. Ein eigenes SIEM oder eine Detection-Plattform wie Wazuh, Elastic Security oder Sentinel gibt Kontrolle über die eigenen Regeln und die eigenen Daten, sie verlangt aber Mitarbeitende mit Detection-Engineering-Skills. Ein Managed-XDR-Anbieter liefert die Engines mit, übernimmt aber auch die Regel-Logik. Wer NIS2-Auditierbarkeit braucht und eine eigene Cyber-Strategie verfolgt, kommt mittelfristig nicht ohne Detection-Engineering-Kompetenz im Haus aus.