Und Detection Engineering: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Detection Engineering ist die systematische Entwicklung, Validierung und Pflege von Erkennungslogik für sicherheitsrelevante Aktivitäten. Im Purple Teaming ist das kein Nebenthema, sondern der operative Kern: Angriffe werden nicht nur simuliert, sondern gezielt gegen bestehende Sichtbarkeit, Telemetrie und Alarmierungslogik gefahren. Erst dadurch wird messbar, ob eine Organisation Angriffe tatsächlich erkennt oder nur annimmt, dass vorhandene Tools ausreichend Schutz liefern.

Der Unterschied zwischen allgemeiner Threat Detection und Detection Engineering liegt in der Arbeitsweise. Threat Detection beschreibt das Ziel, bösartige Aktivitäten zu erkennen. Detection Engineering beschreibt den technischen und organisatorischen Prozess, dieses Ziel reproduzierbar zu erreichen. Dazu gehören Datenquellen, Feldqualität, Normalisierung, Korrelation, Ausnahmelogik, Testfälle, Versionierung und Nachweisbarkeit. Wer das Thema vertiefen will, findet angrenzende Grundlagen unter Und Threat Detection, operative Plattformaspekte unter Und Siem und Endpunktperspektiven unter Und Edr.

Im Purple-Team-Kontext wird Detection Engineering besonders wertvoll, weil Red- und Blue-Perspektive gleichzeitig einfließen. Das Red Team oder der Angriffsoperator liefert realistische TTPs, Variationen und Umgehungstechniken. Das Blue Team bewertet, welche Telemetrie vorhanden ist, welche Felder belastbar sind und welche Regeln in der Praxis zu viel Rauschen erzeugen. Daraus entsteht keine theoretische Liste von Ideen, sondern eine belastbare Detection mit klarer Aussage: Welche Aktivität wird erkannt, unter welchen Bedingungen, mit welcher Datenbasis und mit welchen bekannten Grenzen.

Ein häufiger Denkfehler besteht darin, Detection Engineering mit dem Schreiben einzelner SIEM-Regeln gleichzusetzen. In der Praxis beginnt die Arbeit deutlich früher. Zuerst muss klar sein, welches Verhalten erkannt werden soll. Danach wird geprüft, ob die relevanten Daten überhaupt vorhanden sind. Anschließend folgt die Modellierung der Erkennungslogik, dann die Validierung gegen echte oder simulierte Angriffe, danach Tuning und schließlich die Übergabe in den Betrieb. Ohne diesen Ablauf entstehen Regeln, die zwar syntaktisch korrekt sind, aber operativ wertlos bleiben.

Gutes Detection Engineering arbeitet verhaltensbasiert statt rein indikatorbasiert. Ein Hash, eine IP oder ein Domainname kann kurzfristig nützlich sein, ist aber selten langlebig. Verhalten wie verdächtige Prozessketten, ungewöhnliche Authentifizierungssequenzen, Missbrauch legitimer Admin-Tools oder atypische Datenbewegungen bleibt deutlich robuster. Genau deshalb ist die Verbindung zu Und Mitre Attack so wichtig: ATT&CK liefert eine gemeinsame Sprache für Techniken, Sub-Techniken und beobachtbare Verhaltensmuster.

Detection Engineering ist außerdem kein einmaliges Projekt. Jede neue Anwendung, jede Änderung an Logging-Pipelines, jede EDR-Richtlinie, jede Cloud-Integration und jede neue Angreifertechnik verändert die Erkennungslage. Deshalb muss Detection Engineering als kontinuierlicher Prozess verstanden werden, eng verzahnt mit Workflow, Incident Response, Threat Hunting und Plattformbetrieb. Wer nur punktuell Regeln schreibt, baut keine Detection Capability auf. Wer dagegen Hypothesen, Datenquellen, Tests und Tuning dauerhaft pflegt, schafft eine belastbare Verteidigungsfähigkeit.

Der sauberste Einstieg in Detection Engineering ist nicht die Frage, welche Regel geschrieben werden soll, sondern welche Angriffshypothese geprüft wird. Eine Hypothese beschreibt ein realistisches Angreiferverhalten in einer konkreten Umgebung. Beispiel: Ein Angreifer nutzt gestohlene Zugangsdaten, meldet sich interaktiv auf einem Server an, startet ein Living-off-the-Land-Werkzeug und bewegt sich anschließend lateral weiter. Diese Hypothese ist deutlich wertvoller als die abstrakte Forderung, verdächtige PowerShell zu erkennen.

Aus der Hypothese werden Beobachtungspunkte abgeleitet. Welche Systeme sind betroffen? Welche Logquellen liefern Signale? Welche Felder werden benötigt? Welche Normalisierung findet statt? Welche legitimen Prozesse sehen ähnlich aus? Erst wenn diese Fragen beantwortet sind, lässt sich eine Detection formulieren, die nicht nur im Labor, sondern auch im Betrieb funktioniert.

• Angriffshypothese definieren: Zielsysteme, Technik, erwartetes Verhalten, mögliche Variationen
• Telemetrie prüfen: Welche Datenquellen liefern die nötigen Ereignisse und mit welcher Qualität
• Erkennungslogik modellieren: Einzelereignis, Sequenz, Korrelation, Baseline oder Anomalie
• Testen und validieren: Simulation, Replay, kontrollierte Ausführung, False Positives und False Negatives
• Tunen und dokumentieren: Schwellenwerte, Ausnahmen, bekannte Lücken, Verantwortlichkeiten

In Purple-Team-Übungen wird dieser Ablauf oft zu stark verkürzt. Es wird ein Angriff ausgeführt, ein Alert ausgelöst und das Ergebnis als Erfolg verbucht. Das ist zu wenig. Eine belastbare Detection muss auch Varianten erkennen. Wenn eine Regel nur exakt den Testfall erkennt, aber bereits bei leicht veränderten Parametern versagt, ist keine echte Resilienz vorhanden. Gute Detection Engineers testen deshalb nicht nur den Happy Path, sondern auch Abwandlungen: anderer Parent-Prozess, andere Benutzerkontexte, andere Hostrollen, andere Zeitfenster, andere Codierung, andere Befehlszeilenparameter.

Ein weiterer zentraler Punkt ist die Trennung zwischen Detektionsziel und Implementierungsdetails. Das Ziel könnte lauten: Erkenne verdächtige Credential-Dumping-Aktivität auf Windows-Servern. Die Implementierung kann dann EDR-Telemetrie, Security-Logs, Sysmon oder Speicherzugriffsereignisse nutzen. Wenn das Ziel sauber beschrieben ist, kann die Implementierung später angepasst werden, ohne dass die fachliche Aussage verloren geht. Genau diese Trennung macht Detection Engineering skalierbar.

In reifen Teams wird jede Detection als Produkt betrachtet. Sie besitzt einen Namen, eine fachliche Beschreibung, ein Mapping auf TTPs, Datenquellen, Testfälle, Schweregrad, Triage-Hinweise und einen Owner. Das reduziert Wissensverlust und verhindert, dass Regeln nach einigen Monaten niemand mehr versteht. Besonders in größeren Umgebungen mit Und Soc, mehreren Plattformen und wechselnden Analysten ist diese Produktperspektive entscheidend.

Praktisch bewährt hat sich ein Ablauf, der eng mit Prozess und Playbook verzahnt ist. Detection Engineering endet nicht mit dem Auslösen eines Alerts. Erst wenn klar ist, wie Analysten den Alarm bewerten, welche Kontextdaten verfügbar sind und welche Reaktionsschritte folgen, wird aus einer Regel eine operative Fähigkeit.

Die beste Erkennungslogik scheitert, wenn die Telemetrie unvollständig, verspätet oder falsch normalisiert ist. Detection Engineering beginnt deshalb immer mit Datenqualität. In vielen Umgebungen existieren zwar zahlreiche Logs, aber nur ein Teil davon ist für belastbare Erkennung nutzbar. Typische Probleme sind fehlende Prozessargumente, abgeschnittene Befehlszeilen, uneinheitliche Hostnamen, nicht aufgelöste Benutzeridentitäten, inkonsistente Zeitstempel oder aggressive Filterung bereits auf Collector-Ebene.

Besonders kritisch ist die Feldsemantik. Ein Feldname wie user, account, principal oder subject kann je nach Quelle etwas anderes bedeuten. Wer Regeln über mehrere Datenquellen hinweg baut, muss genau wissen, ob ein Feld den initiierenden Benutzer, den Zielbenutzer oder den technisch ausführenden Dienstaccount beschreibt. Schon kleine Missverständnisse führen zu falschen Korrelationen und damit zu blinden Flecken oder unnötigem Alarmrauschen.

Für Endpunkte sind Prozessstarts, Parent-Child-Beziehungen, Image-Pfade, Signaturinformationen, Netzwerkverbindungen, Registry-Änderungen, Treiberladungen und Speicherzugriffe oft entscheidend. Für Identitätsangriffe sind Authentifizierungsereignisse, Protokolltypen, Quell-IP, Device-Informationen, MFA-Status und Session-Metadaten relevant. In Cloud-Umgebungen kommen API-Calls, Rollenwechsel, Token-Nutzung, Storage-Zugriffe und Control-Plane-Aktivitäten hinzu. Detection Engineering muss diese Heterogenität beherrschen, statt sie zu ignorieren.

Ein häufiger Fehler ist die Annahme, dass mehr Logs automatisch bessere Detection bedeuten. Das Gegenteil ist oft der Fall. Wenn Daten ungefiltert, unnormalisiert und ohne Qualitätskontrolle eingespeist werden, steigt die Komplexität schneller als der Nutzen. Gute Teams definieren deshalb für jede Detection explizit, welche Felder zwingend erforderlich sind, welche optional sind und welche Qualitätskriterien gelten. Dazu gehört auch die Frage, wie hoch die Latenz zwischen Ereignis und Verfügbarkeit im Analyse-Backend ist. Eine Detection, die erst 20 Minuten nach dem Ereignis feuert, kann für schnelle Angriffe operativ wertlos sein.

Praxisnah ist ein Telemetrie-Review vor jeder größeren Purple-Team-Übung. Dabei wird nicht nur geprüft, ob Logs grundsätzlich ankommen, sondern ob sie für die geplanten TTPs ausreichen. Wenn etwa LSASS-Zugriffe erkannt werden sollen, aber der EDR auf kritischen Servern im eingeschränkten Modus läuft, muss diese Lücke vor dem Test bekannt sein. Gleiches gilt für PowerShell-Logging, Script Block Logging, AMSI, Sysmon-Konfigurationen oder Cloud-Audit-Trails.

Ein belastbarer Workflow dokumentiert pro Detection mindestens Datenquelle, Pflichtfelder, erwartete Ereignisrate, bekannte Lücken und Validierungsstatus. Diese Disziplin ist eng verwandt mit Und Log Analyse und wird in der Praxis oft unterschätzt. Viele Fehlalarme entstehen nicht durch schlechte Ideen, sondern durch schlechte Daten. Viele verpasste Erkennungen ebenfalls.

Wer Detection Engineering ernst nimmt, behandelt Telemetrie wie Produktionsinfrastruktur. Änderungen an Parsern, Feldnamen, Agent-Versionen oder Retention dürfen nicht unkontrolliert erfolgen. Sonst brechen funktionierende Regeln stillschweigend. Genau deshalb gehören Monitoring auf Datenpipelines, Parser-Tests und Regressionstests für kritische Detection Use Cases zum Standard.

Gutes Regeldesign beginnt mit der Frage, welches Verhalten von legitimer Aktivität abweicht und gleichzeitig mit vertretbarem Aufwand beobachtbar ist. Eine Detection ist dann stark, wenn sie ein Angreiferziel oder eine Angreifertechnik abbildet, ohne zu eng an ein einzelnes Tool gebunden zu sein. Wer nur auf bekannte Toolnamen oder starre Strings prüft, verliert sofort, sobald ein Operator Parameter ändert, Binärdateien umbenennt oder alternative Werkzeuge nutzt.

Verhaltensbasierte Detection kann auf mehreren Ebenen arbeiten: Einzelereignisse, Sequenzen, Korrelationen über Zeit, Rollen- oder Asset-Kontext, statistische Abweichungen und Kombinationen daraus. Ein einzelner Prozessstart von rundll32.exe ist meist harmlos. Rundll32 mit ungewöhnlichem DLL-Pfad, gestartet durch ein Office-Produkt, gefolgt von Netzwerkkommunikation zu einem seltenen Ziel und anschließendem Credential Access, ist deutlich aussagekräftiger. Die Stärke liegt in der Kombination.

Ein praxistaugliches Regeldesign berücksichtigt immer drei Dimensionen: Signalstärke, Umgehbarkeit und Betriebsrauschen. Eine sehr enge Regel hat oft hohe Präzision, aber geringe Robustheit. Eine sehr breite Regel erkennt mehr Varianten, erzeugt aber mehr False Positives. Detection Engineering ist deshalb immer ein Balanceakt. Ziel ist nicht die perfekte Regel, sondern die beste operative Wirkung unter realen Bedingungen.

Typische Muster für robuste Detection sind verdächtige Prozessketten, Missbrauch administrativer Werkzeuge außerhalb üblicher Rollen, ungewöhnliche Authentifizierungsfolgen, verdächtige Persistenzmechanismen, atypische Datenzugriffe und seltene Kombinationen aus Benutzer, Host, Zeit und Aktion. In Plattformen wie Und Xdr oder EDR lassen sich solche Muster oft mit zusätzlichem Kontext anreichern, etwa Signaturstatus, Device-Risk, Benutzerrolle oder Häufigkeit im historischen Vergleich.

Ein Beispiel für schwaches Regeldesign wäre: Alarmiere auf den String "mimikatz" in der Command Line. Ein stärkeres Design wäre: Alarmiere auf Prozesse mit Speicherzugriff auf LSASS, ungewöhnliche Handle-Rechte, verdächtige MiniDump-Erzeugung, nachfolgende Dateiablage in atypischen Pfaden und optional korrelierte EDR-Indikatoren. Das zweite Modell ist aufwendiger, aber deutlich widerstandsfähiger gegen triviale Umgehung.

Auch Suppression und Ausnahmen gehören zum Regeldesign. Ausnahmen dürfen jedoch nie pauschal formuliert werden. Eine Ausnahme wie "ignoriere alle Aktivitäten von Admins" zerstört die Detection. Sauber sind enge Ausnahmen mit Begründung, Scope und Ablaufdatum, etwa für einen bestimmten Wartungsserver, ein definiertes Deployment-Fenster oder ein signiertes internes Tool mit klarer Prozesskette. Alles andere erzeugt langfristig blinde Flecken.

Regeln sollten außerdem lesbar und wartbar bleiben. Komplexität ist kein Qualitätsmerkmal. Wenn eine Detection nur von einer Person verstanden wird, ist sie operativ riskant. Gute Teams versionieren ihre Regeln, dokumentieren Annahmen und halten Testfälle direkt an der Detection. Das ist besonders wichtig, wenn Regeln in Mit Splunk, Mit Elk Stack oder plattformspezifischen EDR-Sprachen parallel gepflegt werden.

Eine Detection ist erst dann belastbar, wenn sie validiert wurde. Validierung bedeutet mehr als ein einmaliger Test. Es geht darum, nachzuweisen, dass die Erkennung unter definierten Bedingungen funktioniert, Varianten abdeckt und im Betrieb handhabbar bleibt. Purple Teaming liefert dafür den idealen Rahmen, weil Angriffsaktivitäten kontrolliert, dokumentiert und wiederholbar ausgeführt werden können.

In der Praxis haben sich drei Testarten bewährt. Erstens kontrollierte Einzeltests für eine konkrete Technik, etwa verdächtige PowerShell-Ausführung oder Credential Dumping. Zweitens Sequenztests, bei denen mehrere Schritte einer Angriffskette kombiniert werden. Drittens Replay- oder Simulationstests mit historischen Daten oder aufgezeichneten Events. Jede Testart deckt andere Schwächen auf. Einzeltests prüfen die Grundfunktion, Sequenztests die Korrelation, Replay-Tests die Stabilität gegen reale Datenmengen und Feldvarianten.

• Positivtest: Die definierte bösartige Aktivität muss zuverlässig erkannt werden
• Negativtest: Nahe legitime Aktivität darf keinen unnötigen Alarm auslösen
• Variantentest: Kleine Änderungen an Parametern, Pfaden, Encodings oder Parent-Prozessen müssen bewertet werden
• Regressionstest: Nach Parser-, Plattform- oder Regeländerungen darf die Detection nicht unbemerkt brechen

Ein häufiger Fehler in Purple-Team-Übungen ist die fehlende Zeitsynchronisation zwischen Angriffsprotokoll und Telemetrie. Wenn nicht sauber dokumentiert wird, wann welcher Schritt ausgeführt wurde, ist die spätere Analyse unnötig schwierig. Gute Teams arbeiten mit exakten Zeitmarken, eindeutigen Test-IDs und klaren Operator-Notizen. So lässt sich nachvollziehen, ob eine Detection zu spät, gar nicht oder nur unter bestimmten Randbedingungen ausgelöst hat.

Wichtig ist auch die Trennung zwischen Testartefakten und produktiver Erkennung. Manche Tests erzeugen sehr charakteristische Spuren, die im Alltag kaum vorkommen. Wenn eine Detection nur auf diese Testartefakte reagiert, ist sie fachlich schwach. Deshalb sollten Testfälle möglichst realistische Operator-Techniken verwenden und nicht nur Standard-Demos. Das gilt besonders bei Themen wie Angriffe Simulieren, bei denen die Versuchung groß ist, bekannte Beispielbefehle unverändert zu übernehmen.

Ein sauberer Validierungsworkflow enthält neben dem technischen Ergebnis auch eine Analystenperspektive. Wurde der Alert verständlich dargestellt? Waren die relevanten Felder sichtbar? Konnte die Triage ohne manuelle Zusatzsuche erfolgen? Gab es genug Kontext, um Priorität und Scope zu bewerten? Detection Engineering endet nicht beim Triggern, sondern bei der Nutzbarkeit im operativen Betrieb.

Für wiederkehrende Tests lohnt sich eine Bibliothek standardisierter Szenarien, eng gekoppelt an Uebungen und Labs. So werden Detection-Tests reproduzierbar, vergleichbar und über Teams hinweg nutzbar. Reife Organisationen bauen daraus Regression-Suites, die nach Änderungen an Parsern, Agenten oder Regeln automatisch ausgeführt werden.

Die meisten Detection-Programme scheitern nicht an fehlenden Tools, sondern an wiederkehrenden handwerklichen Fehlern. Einer der häufigsten ist die Verwechslung von Aktivität und Risiko. Nicht jede seltene oder ungewöhnliche Aktion ist automatisch bösartig. Wenn Regeln ohne Kontext gebaut werden, entsteht Alarmmüdigkeit. Analysten verlieren Vertrauen in die Detection, und echte Signale gehen im Rauschen unter.

Ebenso problematisch ist das blinde Kopieren von Community-Regeln. Externe Regeln können wertvolle Ausgangspunkte sein, aber sie passen selten unverändert zur eigenen Telemetrie, Feldstruktur und Betriebsrealität. Wer Regeln importiert, ohne Datenquellen, Parser und legitime Nutzungsmuster zu prüfen, produziert entweder tote Regeln oder Fehlalarme. Detection Engineering verlangt Anpassung an die konkrete Umgebung.

Ein weiterer Klassiker ist die fehlende Ownership. Regeln werden einmal erstellt, aber niemand fühlt sich für Tuning, Review und Lebenszyklus verantwortlich. Nach einigen Monaten weiß niemand mehr, warum eine Ausnahme existiert, welche TTP abgedeckt wird oder ob die Detection überhaupt noch feuert. Solche Regeln altern schnell und werden zu technischem Ballast.

Besonders teuer wird es, wenn Detection ohne Asset- und Identitätskontext gebaut wird. Ein Prozessstart auf einem Entwickler-Notebook ist anders zu bewerten als derselbe Prozess auf einem Domain Controller. Ein Service Account mit Batch-Rechten ist anders zu behandeln als ein interaktiver Benutzer mit privilegierter Rolle. Ohne Kontext bleibt die Detection entweder zu breit oder zu eng.

Auch falsche Erfolgskriterien richten Schaden an. Wenn Teams nur die Anzahl neuer Regeln messen, entsteht ein Anreiz für Masse statt Qualität. Zehn neue Alerts mit schlechter Präzision sind weniger wert als eine robuste Detection mit klarer Triage und nachgewiesener Abdeckung. Sinnvoller sind Metriken wie Testabdeckung, mittlere Triage-Zeit, False-Positive-Rate, Stabilität nach Plattformänderungen und Anteil validierter ATT&CK-Techniken.

Ein oft übersehener Fehler ist die fehlende Zusammenarbeit zwischen Detection Engineers und Analysten. Wenn die Person, die eine Regel baut, nie erlebt, wie der Alert im SOC ankommt, fehlen wichtige Rückkopplungen. Gute Detection muss triagierbar sein. Dazu gehören verständliche Titel, klare Begründung, relevante Entitäten, Zeitbezug, Host- und Benutzerkontext sowie Hinweise auf nächste Prüfschritte. Die Verbindung zu Und Alerting ist hier direkt: Ein technisch korrekter Trigger ohne brauchbare Alarmgestaltung bleibt operativ schwach.

Schließlich scheitern viele Programme an fehlender Iteration. Detection Engineering ist kein linearer Vorgang. Nach jedem Test, jedem Incident und jeder größeren Infrastrukturänderung müssen Annahmen überprüft werden. Genau deshalb sind Themen wie Iteration, Fehler und Typische Fehler Beim Purple Teaming keine Randthemen, sondern Kernbestandteile eines reifen Betriebs.

Tuning ist kein kosmetischer Schritt nach der Regelentwicklung, sondern ein integraler Bestandteil. Jede Detection bewegt sich in einem Spannungsfeld zwischen Sensitivität und Präzision. Zu empfindliche Regeln erzeugen Rauschen, zu enge Regeln übersehen Varianten. Das Ziel ist nicht null False Positives, sondern ein Verhältnis, das operativ tragfähig ist und echte Angriffe nicht ausblendet.

Sauberes Tuning beginnt mit der Analyse echter Alarmdaten. Welche Hosts erzeugen die meisten Treffer? Welche Benutzerrollen sind betroffen? Welche Prozesse, Pfade oder Zeitfenster dominieren? Welche Treffer sind erwartbare Admin-Aktivität, welche resultieren aus Softwareverteilung, Backup, Monitoring oder internen Automatisierungen? Erst auf dieser Basis lassen sich Ausnahmen formulieren, ohne die Detection zu entwerten.

Priorisierung darf nicht nur auf dem technischen Signal beruhen. Ein mittelstarkes Signal auf einem hochkritischen Asset kann wichtiger sein als ein starkes Signal auf einem isolierten Testsystem. Deshalb sollten Detection und Alerting immer Asset-Kritikalität, Benutzerrolle, Exponierung, bekannte Schwachstellen und laufende Incidents berücksichtigen. In reifen Umgebungen wird diese Kontextanreicherung direkt in SIEM, EDR oder XDR umgesetzt.

Ein praxistauglicher Ansatz ist die Staffelung in mehrere Schichten. Eine breite, niedrig priorisierte Detection sammelt verdächtige Aktivität für Hunting und Trendanalyse. Eine engere, hoch priorisierte Detection alarmiert nur bei starker Evidenz. So lässt sich Sichtbarkeit erhöhen, ohne das SOC zu überlasten. Diese Trennung ist besonders nützlich, wenn Teams parallel an Und Threat Hunting und operativer Alarmierung arbeiten.

• Ausnahmen immer eng und nachvollziehbar formulieren, niemals global und unbegrenzt
• Schwellenwerte auf Basis realer Umgebungsdaten setzen, nicht nach Bauchgefühl
• Alarmkontext anreichern: Asset-Kritikalität, Benutzerrolle, Parent-Prozess, Historie
• Regeln regelmäßig gegen neue Software, Admin-Workflows und Infrastrukturänderungen prüfen

False Positives haben nicht nur operative Kosten, sondern auch psychologische. Wenn Analysten wiederholt irrelevante Alerts sehen, sinkt die Aufmerksamkeit für spätere Treffer. Deshalb muss Tuning konsequent betrieben werden. Gleichzeitig darf Tuning nicht in Überanpassung umschlagen. Eine Detection, die nur noch in exakt einem Testfall feuert, ist zwar ruhig, aber wertlos. Gute Teams dokumentieren deshalb jede Tuning-Entscheidung mit Begründung und prüfen gezielt, ob dadurch neue Blind Spots entstehen.

Auch die Zeitdimension ist wichtig. Manche Regeln sind tagsüber laut, nachts aber hochrelevant. Andere sind während Wartungsfenstern erwartbar, außerhalb jedoch verdächtig. Zeitbasierte Modelle, Rollenmodelle und Hostgruppen helfen, Präzision zu steigern, ohne die fachliche Aussage zu verlieren. Genau hier zeigt sich, ob Detection Engineering als Handwerk verstanden wird oder nur als Sammlung statischer Suchabfragen.

Detection Engineering skaliert nur mit sauberen Workflows. Regeln, Parser, Ausnahmen und Testfälle müssen versioniert werden. Änderungen brauchen Reviews. Ergebnisse aus Purple-Team-Übungen müssen nachvollziehbar in Backlogs, Detection Stories oder Engineering-Tickets überführt werden. Ohne diese Disziplin bleibt Detection abhängig von Einzelpersonen und verliert bei Teamwechseln schnell an Qualität.

Eine gute Detection-Dokumentation beantwortet mindestens folgende Fragen: Welches Verhalten wird erkannt? Welche ATT&CK-Technik ist betroffen? Welche Datenquellen und Felder werden benötigt? Welche Logik wird angewendet? Welche bekannten False Positives existieren? Welche Ausnahmen sind aktiv? Wie wurde die Detection validiert? Welche Triage-Schritte sind empfohlen? Wer ist verantwortlich? Diese Informationen müssen nicht in langen Fließtexten versteckt sein, aber sie müssen vorhanden und aktuell sein.

Versionierung ist besonders wichtig, wenn dieselbe Detection in mehreren Plattformen existiert. Eine Logik kann in SIEM, EDR und XDR unterschiedlich implementiert sein. Ohne klare Referenz verliert das Team schnell den Überblick, welche Variante aktuell ist und welche Tests dazu gehören. Deshalb sollten Detection-IDs, Test-IDs und Change-Historien konsistent geführt werden.

Die Übergabe in den Betrieb ist ein kritischer Punkt. Eine Detection, die im Engineering-Team gut aussieht, kann im SOC scheitern, wenn Alarmtexte unklar sind, Kontext fehlt oder Eskalationspfade nicht definiert sind. Deshalb sollte jede neue oder geänderte Detection gemeinsam mit Analysten geprüft werden. Dazu gehören Beispiel-Alerts, Triage-Leitfäden und klare Kriterien für Eskalation, Schließung oder Weiterleitung.

In der Praxis bewährt sich ein Workflow mit klaren Statusstufen: Entwurf, Datenprüfung, Implementierung, Test, Tuning, produktiv, Review fällig, außer Betrieb. So wird sichtbar, wo eine Detection im Lebenszyklus steht. Diese Arbeitsweise passt gut zu Dokumentation, Reporting und Best Practices.

Ein weiterer Erfolgsfaktor ist die enge Verzahnung mit Change Management. Neue Anwendungen, Agent-Upgrades, Parser-Änderungen, Cloud-Migrationen oder Logging-Kostenoptimierungen haben direkte Auswirkungen auf Detection. Wenn Security-Engineering davon erst nachträglich erfährt, entstehen Lücken. Reife Teams verankern Detection-Reviews deshalb in technischen Änderungen, nicht erst nach Incidents.

Schließlich gehört auch das kontrollierte Abschalten von Detection zum Workflow. Manche Regeln verlieren durch Plattformwechsel, neue Produkte oder geänderte Prozesse ihre Relevanz. Statt veraltete Regeln mitzuschleppen, sollten sie sauber stillgelegt, dokumentiert und bei Bedarf ersetzt werden. Das hält die Detection-Landschaft wartbar und reduziert unnötige Komplexität.

Detection Engineering braucht Metriken, aber die falschen Kennzahlen führen in die Irre. Die reine Anzahl von Regeln, Alerts oder Datenquellen sagt wenig über tatsächliche Erkennungsfähigkeit aus. Entscheidend ist, ob relevante Angriffsverhalten unter realen Bedingungen erkannt, triagiert und in angemessener Zeit bearbeitet werden können.

Sinnvolle Metriken orientieren sich an Abdeckung, Qualität und Betriebsfähigkeit. Abdeckung meint nicht nur die Anzahl gemappter ATT&CK-Techniken, sondern den validierten Nachweis, dass konkrete TTPs in der eigenen Umgebung erkennbar sind. Qualität umfasst Präzision, Robustheit gegen Varianten und Stabilität nach Änderungen. Betriebsfähigkeit bewertet, ob Alerts verständlich, priorisierbar und mit vertretbarem Aufwand bearbeitbar sind.

Praktisch nützliche Kennzahlen sind etwa der Anteil validierter Detection Use Cases, die mittlere Zeit von Hypothese bis produktiver Detection, die False-Positive-Rate pro Regelklasse, die Anzahl regressionsgetesteter kritischer Regeln, die mittlere Triage-Zeit und die Quote von Alerts mit ausreichendem Kontext. Auch die Zeit bis zur Anpassung nach neuen Angriffserkenntnissen ist ein guter Reifeindikator.

Wichtig ist, Metriken nicht isoliert zu betrachten. Eine sinkende Alert-Zahl kann auf besseres Tuning hindeuten, aber auch auf gebrochene Parser oder deaktivierte Telemetrie. Eine hohe ATT&CK-Abdeckung kann beeindruckend wirken, obwohl nur oberflächliche Einzelereignisse erkannt werden. Deshalb müssen Kennzahlen immer mit Testnachweisen und Datenqualitätsindikatoren kombiniert werden.

Reife Detection-Programme arbeiten mit regelmäßigen Review-Zyklen. Kritische Detection Use Cases werden in festen Abständen erneut getestet, besonders nach Infrastrukturänderungen oder neuen Bedrohungslagen. Ergebnisse fließen in Roadmaps, Priorisierung und Engineering-Backlogs ein. Die Verbindung zu Metriken und Erfolg Messen ist dabei direkt: Fortschritt wird nicht behauptet, sondern anhand reproduzierbarer Tests und belastbarer Daten nachgewiesen.

Ein realistischer Reifegrad zeigt sich auch daran, wie mit Lücken umgegangen wird. Nicht jede Technik lässt sich sofort sauber erkennen. Entscheidend ist, ob diese Lücken bekannt, priorisiert und mit konkreten Maßnahmen hinterlegt sind. Detection Engineering ist dann professionell, wenn Unsicherheit sichtbar gemacht wird, statt sie hinter einer großen Zahl von Regeln zu verstecken.

Ein praxisnahes Beispiel verdeutlicht, wie Detection Engineering im Purple Teaming abläuft. Ausgangslage ist eine interne Windows-Umgebung mit EDR, zentralem SIEM und Active Directory. Die Angriffshypothese lautet: Ein Angreifer erhält Zugriff auf einen Benutzerarbeitsplatz, führt Discovery aus, nutzt PowerShell für Download und Ausführung, versucht Credential Access und bewegt sich anschließend lateral per Remote Service oder WMI.

Schritt eins ist die Zerlegung in beobachtbare Teilverhalten. Discovery erzeugt oft Prozessstarts typischer Systemwerkzeuge, Verzeichnisabfragen, Netzwerkscans oder LDAP-bezogene Aktivitäten. PowerShell kann über Prozessargumente, Script Block Logging, AMSI oder EDR-Telemetrie sichtbar werden. Credential Access kann Speicherzugriffe, Dump-Dateien oder verdächtige Handle-Rechte erzeugen. Lateral Movement hinterlässt Authentifizierungsereignisse, Service-Erstellung, Remote-Prozessstarts oder WMI-Aktivität.

Schritt zwei ist die Datenprüfung. Sind PowerShell-Logs vollständig? Liefert der EDR Parent-Child-Beziehungen und Command Lines? Sind Security-Events für Service-Erstellung zentral verfügbar? Gibt es WMI-Operational-Logs oder alternative Telemetrie? Ohne diese Prüfung würde die spätere Detection auf Annahmen beruhen.

Schritt drei ist das Regeldesign. Statt eine einzige Mega-Regel zu bauen, wird die Angriffskette in mehrere Detection Use Cases zerlegt: verdächtige PowerShell-Ausführung, ungewöhnlicher Zugriff auf LSASS, Remote-Service-Erstellung außerhalb definierter Admin-Hosts, WMI-Ausführung mit seltenem Benutzerkontext, Sequenz aus interaktiver Anmeldung und nachfolgendem Remote-Execution-Muster. Diese Zerlegung verbessert Wartbarkeit und Triage.

Schritt vier ist die Validierung. Der Operator führt die geplanten Aktionen kontrolliert aus. Jede Aktion erhält Zeitmarken und Test-IDs. Anschließend wird geprüft, welche Detection ausgelöst hat, welche Felder sichtbar waren und ob die Alarmtexte für Analysten ausreichen. Wenn etwa die PowerShell-Detection feuert, aber keine Command Line oder kein Benutzerkontext sichtbar ist, muss nachgebessert werden. Wenn die LSASS-Detection nur bei einem bekannten Testtool, nicht aber bei einer leicht veränderten Methode anspringt, ist die Logik zu eng.

Schritt fünf ist das Tuning. Vielleicht erzeugt die Remote-Service-Detection viele Treffer durch Softwareverteilung. Dann wird nicht pauschal ausgeschlossen, sondern gezielt auf bekannte Deployment-Server, signierte Prozesse oder definierte Wartungsfenster eingeschränkt. Vielleicht ist WMI in bestimmten Admin-Teams legitim. Dann wird Rollen- und Hostkontext ergänzt, statt die Detection abzuschalten.

Schritt sechs ist die Betriebsübergabe. Für jede Detection werden Triage-Hinweise dokumentiert: Welche Folgeereignisse prüfen? Welche Hosts priorisieren? Welche Benutzerrollen sind kritisch? Welche Artefakte sichern? So wird aus einer Testübung eine operative Verbesserung. Genau dieser Übergang macht den Unterschied zwischen einer einmaligen Demonstration und echtem Detection Engineering im Sinne von Purple Teaming.

Wer solche Szenarien systematisch aufbaut, erhält mit der Zeit eine belastbare Bibliothek aus Use Cases, Tests und Tuning-Erfahrungen. Das ist deutlich wertvoller als eine lose Sammlung von Regeln. Die Organisation lernt nicht nur, einzelne Angriffe zu erkennen, sondern entwickelt eine wiederholbare Fähigkeit, Detection gezielt zu bauen, zu prüfen und zu verbessern.