It Security Use Case Engineering: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Use Case Engineering beschreibt den strukturierten Aufbau von Erkennungslogik für sicherheitsrelevante Ereignisse. Gemeint ist nicht nur eine einzelne Query in einem SIEM, sondern der komplette Weg von der Bedrohungshypothese über Datenquellen, Normalisierung, Korrelation, Alarmierung, Triage, Tuning und Erfolgsmessung bis in den operativen Betrieb. In vielen Umgebungen wird der Begriff zu eng verwendet. Dort gilt bereits jede Suchanfrage als Use Case. Genau an dieser Stelle entstehen später blinde Flecken, unnötige False Positives und Alarme ohne verwertbaren Kontext.

Ein belastbarer Security-Use-Case beantwortet mehrere Fragen gleichzeitig: Welche Angreifertechnik soll erkannt werden, auf welchen Systemen tritt sie auf, welche Telemetrie ist dafür notwendig, welche Vorbedingungen gelten, wie sieht normales Verhalten aus und welche Reaktion wird nach Auslösung erwartet. Ohne diese Kette bleibt Detection zufällig. Gute Ergebnisse entstehen erst dann, wenn fachliche Bedrohungsmodelle mit real verfügbaren Logs und operativen Prozessen zusammengeführt werden. Die Nähe zu It Security Detection Engineering ist offensichtlich, aber Use Case Engineering geht noch weiter, weil es die fachliche Konstruktion und den Lebenszyklus eines Use Cases in den Mittelpunkt stellt.

Ein typischer Fehler in Security-Teams besteht darin, Use Cases direkt aus Produktfeatures abzuleiten. Dann wird etwa eine EDR-Regel aktiviert, weil sie vorhanden ist, nicht weil sie ein relevantes Risiko adressiert. Das Ergebnis ist ein Katalog aus Regeln ohne Priorisierung, ohne Abdeckungskonzept und ohne Bezug zu den tatsächlichen It Security Bedrohungen der Umgebung. In reifen Teams läuft es umgekehrt: Zuerst wird definiert, welche Angriffswege relevant sind, danach wird geprüft, welche Telemetrie vorhanden ist, und erst dann wird die Erkennungslogik gebaut.

Use Case Engineering ist außerdem eng mit Security Monitoring Use Cases, It Security Log Correlation und It Security Threat Modeling verbunden. Threat Modeling liefert die Hypothesen, Log Correlation verbindet die Signale, Monitoring operationalisiert die Erkennung. Wer diese Disziplinen trennt, produziert meist Regeln, die technisch korrekt aussehen, aber operativ wenig bringen.

In der Praxis muss ein Use Case immer drei Ebenen gleichzeitig bedienen: technische Erkennung, analytische Einordnung und operative Verwertbarkeit. Eine Query, die PowerShell mit Base64 erkennt, ist technisch trivial. Ob daraus ein guter Use Case wird, hängt davon ab, ob Elternprozess, Benutzerkontext, Host-Rolle, Signaturstatus, Befehlszeilenlänge, Netzwerkverbindungen und Folgeaktivitäten berücksichtigt werden. Erst dann lässt sich zwischen Admin-Automation, Softwareverteilung und echter Kompromittierung unterscheiden.

Wer Use Cases sauber entwickelt, reduziert nicht nur Alarmrauschen. Die Qualität von Incident Response steigt, weil Analysten schneller verstehen, warum ein Alarm ausgelöst wurde, welche Hypothese dahintersteht und welche nächsten Schritte sinnvoll sind. Genau deshalb ist Use Case Engineering ein Kernbestandteil moderner It Security Security Operations Center-Arbeit.

Der Startpunkt eines guten Use Cases ist nicht das Logformat, sondern das Risiko. Zuerst wird festgelegt, welches Verhalten erkannt werden soll und warum es relevant ist. Das kann Credential Access über Passwort-Spraying, laterale Bewegung über Remote Services, Datenabfluss über Cloud-Speicher oder Persistenz über geplante Tasks sein. Diese fachliche Definition muss konkret genug sein, damit daraus messbare Signale abgeleitet werden können. Vage Formulierungen wie „verdächtige Anmeldung“ oder „ungewöhnlicher Traffic“ sind unbrauchbar, solange nicht klar ist, wodurch sich Verdacht oder Ungewöhnlichkeit technisch ausdrücken.

Ein praxistauglicher Weg ist die Ableitung aus Angreifertechniken. Modelle wie MITRE ATT&CK helfen, dürfen aber nicht mechanisch übernommen werden. Ein Team muss bewerten, welche Techniken in der eigenen Umgebung realistisch sind. Ein Unternehmen mit starkem Microsoft-Fokus priorisiert andere Use Cases als ein Cloud-natives SaaS-Unternehmen. Ein OT-Netz hat andere Erkennungsanforderungen als ein klassisches Office-Netz. Use Case Engineering ist deshalb immer kontextgebunden.

Vor der technischen Umsetzung sollten mindestens folgende Punkte geklärt sein:

• Welches konkrete Angriffsverhalten oder welche Missbrauchshandlung soll erkannt werden?
• Welche Assets, Identitäten, Anwendungen oder Netzsegmente sind betroffen?
• Welche Datenquellen liefern dafür belastbare Signale und welche Lücken existieren?
• Wie sieht legitimes Verhalten aus und wodurch grenzt es sich vom Missbrauch ab?
• Welche Reaktion soll nach Auslösung des Use Cases erfolgen?

Diese Vorarbeit trennt brauchbare Erkennung von blindem Regelbau. Ein Beispiel: Ein Team möchte Passwort-Spraying erkennen. Ohne Kontext wird einfach auf viele fehlgeschlagene Logins pro Quell-IP alarmiert. In der Realität erzeugen VPN-Gateways, SSO-Fehlkonfigurationen, Health Checks oder falsch konfigurierte Mobile Clients ähnliche Muster. Ein sauber definierter Use Case berücksichtigt deshalb Zielkonten, Verteilung über viele Benutzer, Zeitfenster, Quellreputation, Geo-Kontext, Erfolgsereignisse nach Fehlversuchen und bekannte Service-Quellen. Die Verbindung zu It Security Password Spraying und It Security Account Lockout ist dabei direkt relevant.

Ein weiteres Beispiel ist die Erkennung von Datenabfluss. Viele Teams bauen zunächst Volumenschwellen auf Proxy- oder Firewall-Logs. Das ist selten ausreichend. Ein belastbarer Use Case kombiniert Dateizugriffe, Klassifizierung sensibler Daten, Upload-Ziele, Benutzerrolle, Uhrzeit, Gerätetyp, Verschlüsselungsstatus und Abweichungen vom Normalverhalten. Hier wird deutlich, warum It Security Anomaly Detection sinnvoll sein kann, aber nur dann, wenn die Baseline sauber modelliert wurde.

Die fachliche Phase endet erst, wenn klar ist, welche Hypothese die Erkennung prüft. Eine gute Formulierung lautet etwa: „Erkenne interaktive PowerShell-Ausführung mit obfuskierten Parametern auf Workstations außerhalb definierter Admin-Kontexte, wenn innerhalb von zehn Minuten zusätzlich Netzwerkverbindungen zu seltenen externen Zielen auftreten.“ Das ist präzise, testbar und operativ verwertbar.

Die meisten Detection-Probleme sind keine Query-Probleme, sondern Telemetrie-Probleme. Wenn relevante Felder fehlen, Zeitstempel unzuverlässig sind, Hostnamen nicht konsistent aufgelöst werden oder Prozessketten abgeschnitten sind, kann selbst die beste Logik keine stabile Erkennung liefern. Use Case Engineering muss deshalb immer mit einer nüchternen Bewertung der Datenlage beginnen.

Wichtige Fragen sind: Welche Events existieren tatsächlich, wie vollständig sind sie, wie hoch ist die Verzögerung bis zur Verfügbarkeit, wie lange werden sie aufbewahrt und wie konsistent sind Feldnamen über verschiedene Quellen hinweg. Besonders kritisch ist die Normalisierung. Wenn derselbe Benutzer in einer Quelle als user, in einer anderen als account_name und in einer dritten als principal auftaucht, wird Korrelation unnötig fehleranfällig. Gute Teams definieren ein gemeinsames Datenmodell oder zumindest stabile Mapping-Regeln.

Ein klassisches Beispiel ist die Erkennung verdächtiger Prozessausführung auf Windows-Endpunkten. Ohne Command Line Logging, Parent-Child-Beziehungen, Hashes, Signaturstatus und Benutzerkontext bleibt nur ein grobes Bild. Mit EDR-Telemetrie lässt sich dagegen deutlich präziser arbeiten. Ähnlich verhält es sich im Netzwerk: Reine Firewall-Logs zeigen Verbindungen, aber keine Inhalte. DNS-Logs liefern Namensauflösung, Proxy-Logs zeigen URLs, NDR-Sensoren liefern Verhaltensmuster. Erst die Kombination erzeugt verwertbare Tiefe. Deshalb überschneidet sich Use Case Engineering oft mit It Security Network Detection Response und It Security Endpoint Detection Response.

Ein häufiger Fehler ist die Annahme, dass mehr Logs automatisch bessere Detection bedeuten. In Wirklichkeit steigt mit jeder zusätzlichen Quelle auch die Komplexität: Parsing, Feldmapping, Deduplizierung, Zeitkorrektur, Identitätsauflösung und Storage-Kosten. Reife Teams wählen Datenquellen gezielt nach Erkennungswert aus. Für einen Use Case gegen Webshell-Aktivität sind Webserver-Logs, Prozessstarts auf dem Host, Dateiänderungen im Webroot und ausgehende Verbindungen oft wertvoller als pauschal alle Netzwerkdaten.

Normalisierung darf außerdem nicht zu Informationsverlust führen. Viele SIEM-Pipelines reduzieren Rohdaten auf Standardfelder und verwerfen Details, die später für Tuning oder Forensik fehlen. Ein Beispiel sind gekürzte Command Lines oder fehlende Original-Header in Proxy-Logs. Für Use Case Engineering gilt daher: standardisieren, aber Rohkontext erhalten. Das ist besonders wichtig, wenn Erkennungen später mit It Security Behavioral Analysis oder It Security User Behavior Analytics kombiniert werden.

Auch Zeit ist ein kritischer Faktor. Wenn Cloud-Audit-Logs erst mit mehreren Minuten Verzögerung eintreffen, kann ein Use Case für schnelle Reaktion ungeeignet sein. Dann muss entweder die Erwartung angepasst oder eine andere Quelle ergänzt werden. Gute Use Cases dokumentieren deshalb immer ihre Telemetrie-Annahmen: Datenquelle, Feldabhängigkeiten, bekannte Blind Spots und Mindestqualität der Daten.

Ein guter Use Case besteht selten aus einer einzelnen Bedingung. Belastbare Erkennung entsteht meist durch die Kombination mehrerer atomarer Signale. Ein atomares Signal ist ein einzelnes beobachtbares Ereignis, etwa „powershell.exe mit EncodedCommand“, „Anmeldung aus neuem Land“, „Dienstinstallation auf Server“, „DNS-Anfrage an seltene Domain“ oder „Massenlesezugriff auf sensible Dateien“. Jedes dieser Signale kann legitim sein. Erst ihre Kombination erhöht die Aussagekraft.

Der Kern der Erkennungslogik ist daher die Frage, welche Signale gemeinsam stark genug sind, um Alarm auszulösen. Dabei helfen mehrere Muster: Sequenzkorrelation, Schwellenwerte, Kontextanreicherung, Baseline-Abweichung und Risikoakkumulation. Sequenzkorrelation betrachtet die Reihenfolge von Ereignissen. Schwellenwerte zählen Häufigkeiten. Kontextanreicherung ergänzt Asset-Kritikalität, Benutzerrolle oder Threat-Intel. Baseline-Abweichung vergleicht mit historischem Verhalten. Risikoakkumulation bewertet mehrere schwache Signale gemeinsam.

Ein Beispiel aus der Praxis: Verdacht auf kompromittiertes Administratorkonto. Ein schwacher Indikator wäre eine erfolgreiche Anmeldung außerhalb der üblichen Arbeitszeit. Ein zweiter wäre die Nutzung eines Hosts, den das Konto sonst nie verwendet. Ein dritter wäre die Ausführung von Directory-Reconnaissance-Befehlen. Ein vierter wäre der Zugriff auf mehrere Server in kurzer Folge. Keines dieser Signale allein ist zwingend bösartig. Zusammen entsteht jedoch ein starkes Muster für Missbrauch oder laterale Bewegung.

Die technische Umsetzung muss dabei deterministisch genug sein, um reproduzierbar zu bleiben. Viele Teams bauen zu früh komplexe statistische Modelle, obwohl die Datenbasis dafür nicht stabil genug ist. In den meisten Umgebungen liefern zunächst regelbasierte Korrelationen mit sauberem Kontext die besseren Ergebnisse. Erst wenn Baselines belastbar sind, lohnt sich die Ergänzung durch verhaltensbasierte Verfahren. Die Nähe zu It Security Entity Behavior Analytics ist hier groß, aber regelbasierte Logik bleibt die Grundlage.

Ein praxistaugliches Muster ist die Trennung in drei Ebenen:

• Primitive Detection: einzelne technische Indikatoren wie Prozessname, Event-ID, URL-Muster oder Registry-Änderung.
• Analytische Detection: Kombination mehrerer primitiver Signale zu einer Hypothese wie Credential Access oder Defense Evasion.
• Operative Detection: Alarm mit Priorität, Kontext, Triage-Hinweisen und klarer Eskalationslogik.

Diese Trennung verhindert, dass jede primitive Beobachtung sofort als Incident behandelt wird. Stattdessen können primitive Signale gesammelt, gewichtet und erst bei ausreichender Evidenz eskaliert werden. Genau das reduziert Alarmmüdigkeit und verbessert die Qualität von It Security Alert Triage.

Ein einfaches Beispiel für eine Korrelation könnte so aussehen:

IF
  process_name = "powershell.exe"
  AND command_line CONTAINS "-enc"
  AND parent_process NOT IN ("ccmexec.exe","trusted_admin_tool.exe")
  AND host_role = "workstation"
  AND user_privilege != "approved_admin"
WITHIN 10m
JOIN
  outbound_connection TO rare_external_destination = true
THEN
  create_alert severity = high
  attach_context = process_tree, user_history, destination_reputation

Die Query selbst ist nur ein Teil. Entscheidend ist, dass Ausnahmen bewusst modelliert wurden, Host-Rollen berücksichtigt werden und der Alarm bereits Kontext für die erste Analyse mitliefert. Ohne diese Elemente wird aus einer technisch korrekten Regel schnell ein operatives Problem.

Einzelereignisse sind selten ausreichend, weil Angriffe als Kette stattfinden. Ein Use Case wird deutlich stärker, wenn er in einen realen Angriffsablauf eingebettet ist. Genau deshalb ist die Orientierung an TTPs, Kill Chain oder Angriffspfaden so wertvoll. Wer nur auf einzelne Events schaut, erkennt vielleicht Symptome, aber nicht den Zusammenhang. Wer dagegen die Sequenz versteht, erkennt auch schwächere Signale früher und kann Prioritäten besser setzen.

Ein typischer Ablauf bei initialem Zugriff über Phishing kann so aussehen: Benutzer öffnet schädlichen Anhang, Office-Prozess startet Skriptinterpreter, dieser lädt Payload nach, erzeugt Persistenz und baut C2-Kommunikation auf. Für jede Phase lassen sich atomare Signale definieren. Ein starker Use Case korreliert diese Phasen oder bewertet sie zumindest gemeinsam. Das ist deutlich robuster als eine isolierte Regel auf „winword.exe startet powershell.exe“.

Dasselbe gilt für Webangriffe. Ein Angreifer testet zunächst Eingabepunkte, provoziert Fehler, variiert Header, nutzt Encoding-Tricks und versucht dann gezielt Exploitation. Ein Use Case für Webanwendungen sollte deshalb nicht nur einzelne Requests mit verdächtigen Zeichenfolgen erkennen, sondern auch Muster über Zeit, Quelle, Session und Zielpfad hinweg. Hier entstehen Überschneidungen zu Websecurity Testing, Websecurity API Security und It Security Attack Surface.

Ein weiterer Praxispunkt: Use Cases müssen an die Verteidigungsziele angepasst werden. Manche Erkennungen dienen der frühen Warnung, andere der Bestätigung einer bereits fortgeschrittenen Kompromittierung. Frühe Warnungen haben oft mehr False Positives, liefern aber Zeitgewinn. Späte Bestätigungen sind präziser, kommen aber später. Ein reifes Programm braucht beides. Wer nur hochpräzise Regeln baut, erkennt viele Angriffe zu spät. Wer nur frühe Indikatoren alarmiert, überlastet das SOC.

Deshalb ist es sinnvoll, Use Cases entlang von Angriffsphasen zu staffeln und mit unterschiedlichen Schweregraden zu versehen. Ein verdächtiger Login aus neuem ASN kann Medium sein. Derselbe Login plus MFA-Bypass-Indikatoren plus privilegierte Aktionen wird High. Diese Eskalationslogik ist ein zentraler Bestandteil sauberer Use-Case-Architektur und eng mit It Security Threat Response sowie Defense Playbooks verbunden.

In der Praxis lohnt es sich, für kritische Szenarien Detection Chains zu entwerfen: Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Discovery, Lateral Movement, Collection, Exfiltration. Nicht jede Phase muss perfekt abgedeckt sein. Aber die Kette macht sichtbar, wo Lücken bestehen. Genau dort sollten neue Use Cases priorisiert werden.

Die meisten Fehler entstehen nicht beim Schreiben der Regel, sondern bei Annahmen, die nie überprüft wurden. Ein häufiger Fehler ist fehlende Zieldefinition. Dann wird eine Regel gebaut, ohne dass klar ist, welches Verhalten sie eigentlich erkennen soll. Das Ergebnis sind Alarme mit unklarer Bedeutung. Analysten müssen erst interpretieren, was die Regel wohl gemeint haben könnte. Das kostet Zeit und führt zu inkonsistenter Bewertung.

Ein zweiter Fehler ist die Verwechslung von IOC-Matching mit Detection. Ein Hash, eine Domain oder eine IP kann nützlich sein, aber nur begrenzt. Angreifer wechseln Infrastruktur schnell. Ein Use Case, der fast nur auf statischen Indikatoren basiert, altert schlecht. Robuster sind verhaltensbasierte Merkmale: Prozessketten, ungewöhnliche Authentisierungsmuster, Missbrauch privilegierter Werkzeuge, seltene Admin-Aktionen oder untypische Datenbewegungen.

Ein dritter Fehler ist fehlende Umgebungskenntnis. Eine Regel, die in einem Labor gut funktioniert, kann in der Produktion unbrauchbar sein, weil dort Softwareverteilung, Backup-Agenten, Monitoring-Tools oder Admin-Skripte ähnliche Muster erzeugen. Ohne Asset-Kontext, Wartungsfenster, bekannte Servicekonten und Rollenmodell wird Tuning zum Dauerfeuer. Genau hier zeigen sich viele It Security Typische Fehler im operativen Alltag.

Besonders teuer werden folgende Fehlmuster:

• Regeln ohne dokumentierte Annahmen, Datenabhängigkeiten und bekannte Blind Spots.
• Alarmierung ohne Kontext wie Benutzerhistorie, Host-Kritikalität, Prozessbaum oder Zielreputation.
• Keine Trennung zwischen Test-, Staging- und Produktionslogik.
• Ausnahmen direkt in die Query eingebrannt, ohne Governance oder Ablaufdatum.
• Kein Review nach echten Incidents, wodurch dieselben Fehlalarme dauerhaft bestehen bleiben.

Ein weiterer klassischer Fehler ist die falsche Metrik. Viele Teams bewerten Use Cases nur nach Alarmanzahl. Das ist wertlos. Eine Regel mit vielen Treffern kann schlecht sein, wenn fast alles False Positive ist. Eine Regel mit wenigen Treffern kann hervorragend sein, wenn sie hochkritische Missbrauchsfälle zuverlässig erkennt. Sinnvolle Kennzahlen sind Präzision, mittlere Triage-Zeit, Eskalationsquote, bestätigte Incidents, Abdeckung kritischer TTPs und Zeit bis zur Erkennung.

Auch Ausnahmen werden oft falsch behandelt. Wenn eine Regel zu laut ist, werden ganze Hostgruppen oder Benutzer pauschal ausgeschlossen. Kurzfristig sinkt das Rauschen, langfristig entstehen blinde Flecken. Besser ist eine präzise Ausnahme mit Begründung, Eigentümer, Gültigkeitsdauer und Review-Termin. Sonst wird Tuning zur schleichenden Deaktivierung der Detection.

Schließlich fehlt oft die Rückkopplung aus Incident Response. Jeder echte Vorfall liefert Material für bessere Use Cases: Welche Signale waren früh sichtbar, welche Daten fehlten, welche Felder waren unzuverlässig, welche Korrelation hätte früher alarmieren können. Ohne diese Schleife stagniert das Programm. Gute Teams koppeln Use Case Engineering deshalb eng an It Security Incident Triage und Lessons Learned aus dem Betrieb.

Tuning ist kein kosmetischer Nachschritt, sondern Teil des eigentlichen Engineerings. Jede Detection startet mit Annahmen über normales und bösartiges Verhalten. Diese Annahmen sind anfangs unvollständig. Erst im Betrieb zeigt sich, welche Muster legitim sind, welche Daten verrauscht sind und welche Kontexte fehlen. Tuning bedeutet deshalb nicht einfach „weniger Alarme“, sondern gezielte Verbesserung der Trennschärfe.

Der erste Schritt im Tuning ist die saubere Klassifikation von Treffern. Jeder Alarm sollte als True Positive, Benign True Positive, False Positive oder unklar bewertet werden. Diese Unterscheidung ist wichtig. Ein Benign True Positive erkennt tatsächlich das definierte Verhalten, aber das Verhalten ist in diesem Kontext legitim. Das ist etwas anderes als ein False Positive, bei dem die Regel technisch falsch anschlägt. Die Gegenmaßnahmen unterscheiden sich entsprechend.

Ein Beispiel: Eine Regel erkennt PowerShell mit DownloadString. Auf Admin-Jump-Hosts ist das möglicherweise legitime Automation und damit ein Benign True Positive. Auf Office-Workstations ist es verdächtig. Die Lösung ist nicht, die Regel global abzuschwächen, sondern Kontext einzubauen: Host-Rolle, Benutzergruppe, bekannte Admin-Tools, Wartungsfenster. Genau dadurch steigt Präzision, ohne relevante Erkennung zu verlieren.

Tuning sollte systematisch erfolgen. Zuerst werden dominante Fehlermuster identifiziert, dann wird geprüft, ob sie durch Kontext, Sequenz, Schwellenwert, Baseline oder Ausnahme besser behandelt werden. Ein häufiger Fehler ist das vorschnelle Erhöhen von Schwellenwerten. Dadurch sinkt zwar die Alarmzahl, aber oft auch die Sensitivität. Besser ist meist die Kombination zusätzlicher Merkmale. Statt „mehr als 20 Fehlanmeldungen“ kann etwa „mehr als 10 Fehlanmeldungen gegen mindestens 8 unterschiedliche Konten aus neuer Quelle mit anschließendem Erfolg“ deutlich robuster sein.

Auch die Zusammenarbeit mit Analysten ist entscheidend. Wer Tuning ohne Rückmeldung aus dem SOC betreibt, optimiert an der Realität vorbei. Analysten wissen, welche Felder im Alarm fehlen, welche Artefakte regelmäßig manuell nachrecherchiert werden und welche Ausnahmen immer wieder auftreten. Diese Informationen müssen zurück in die Detection. Die Verbindung zu Security Monitoring Alerting und Security Monitoring Analyse ist hier operativ zentral.

Ein praxistaugliches Tuning-Beispiel:

Initiale Regel:
  Alert bei jeder Ausführung von rundll32.exe mit URL in der Command Line

Problem:
  Viele legitime Software-Updater nutzen ähnliche Muster

Tuning:
  - nur auf Workstations, nicht auf Software-Verteilservern
  - Ausschluss signierter bekannter Updater
  - Priorität erhöhen, wenn Parent-Prozess Office, Browser oder Script Host ist
  - Priorität erhöhen, wenn kurz danach neue Datei im Temp-Verzeichnis entsteht
  - Priorität erhöhen, wenn Netzwerkziel selten oder reputationsschwach ist

Ergebnis:
  Weniger Rauschen, bessere Priorisierung, höhere Aussagekraft

Wichtig ist außerdem, Tuning nicht nur auf False Positives auszurichten. False Negatives sind gefährlicher, aber schwerer sichtbar. Deshalb sollten Use Cases regelmäßig gegen bekannte Angriffssimulationen, Purple-Team-Ergebnisse oder historische Incidents geprüft werden. Nur so lässt sich feststellen, ob eine leiser gewordene Regel noch ausreichend erkennt.

Viele Security-Teams scheitern nicht an der Detection-Idee, sondern an fehlenden Workflows. Regeln werden direkt in Produktion geändert, Ausnahmen per Zuruf eingebaut, Versionen nicht dokumentiert und nach einigen Monaten weiß niemand mehr, warum eine Logik existiert oder wer sie verantwortet. Use Case Engineering braucht deshalb denselben Disziplinierungsgrad wie Softwareentwicklung.

Ein belastbarer Workflow beginnt mit einer formalen Spezifikation. Darin stehen Ziel, Bedrohungshypothese, Datenquellen, Felder, Logik, Schweregrad, Annahmen, bekannte Grenzen, Testfälle, Triage-Hinweise und Eigentümer. Erst danach folgt die technische Implementierung. Diese wird versioniert, reviewt und in einer Testumgebung validiert. Änderungen an produktiven Regeln ohne Review sind ein unnötiges Risiko, weil schon kleine Anpassungen massive Auswirkungen auf Alarmvolumen und Blind Spots haben können.

Besonders wichtig ist die Trennung zwischen fachlicher Logik und plattformspezifischer Syntax. Ein Use Case sollte unabhängig vom konkreten SIEM oder EDR beschrieben werden können. Die Implementierung in Splunk, Sentinel, Elastic oder QRadar ist dann nur die technische Übersetzung. Das erleichtert Reviews, Portierung und Qualitätskontrolle. Wer Logik und Toolsyntax vermischt, macht sich unnötig abhängig von einzelnen Plattformen.

Ein sauberer Workflow umfasst typischerweise Spezifikation, Implementierung, Test, Freigabe, Deployment, Monitoring und Review. In reifen Umgebungen wird zusätzlich mit Detection-as-Code gearbeitet. Regeln liegen in Versionskontrolle, Änderungen laufen über Pull Requests, Tests prüfen Syntax und erwartete Trefferbilder, und Deployments sind nachvollziehbar. Die Nähe zu It Security Devsecops und It Security Secure Development ist hier offensichtlich.

Ein praktisches Minimalformat für eine Use-Case-Spezifikation kann so aussehen:

Name: Suspicious PowerShell Download on Workstations
Ziel: Erkennung möglicher Payload-Nachladung nach User Execution
TTP: Execution / Command and Scripting Interpreter
Datenquellen: EDR Process Events, DNS Logs, Proxy Logs
Voraussetzungen: Command Line Logging aktiv, Host-Rollen gepflegt
Logik: powershell.exe mit DownloadString oder WebClient + externes Ziel + keine freigegebene Admin-Quelle
Schweregrad: High auf Workstations, Medium auf Servern
Ausnahmen: definierte Admin-Jump-Hosts, signierte Deployment-Tools
Triage: Prozessbaum prüfen, Benutzerkontext, Zielreputation, Folgeprozesse, Persistenzartefakte
Tests: simulierte Admin-Automation, simulierte Malware-Nachladung, bekannte legitime Updater
Owner: Detection Engineering
Review-Zyklus: alle 90 Tage oder nach Incident

Im Betrieb muss außerdem klar sein, wer welche Entscheidungen trifft. Detection Engineers bauen und pflegen Logik. SOC-Analysten liefern Feedback aus der Triage. Incident Responder melden Lücken aus echten Fällen. Plattformteams sichern Datenqualität. Ohne diese Rollenklärung entstehen Reibungsverluste. Besonders in größeren Umgebungen lohnt sich die enge Verzahnung mit It Security Blue Team Operations und It Security Soc.

Praxisnahe Use Cases sind immer domänenspezifisch. Auf Endpunkten sind Prozessketten, Script-Ausführung, Persistenzmechanismen und Defense Evasion besonders relevant. Im Identity-Bereich dominieren Anomalien bei Anmeldung, Token-Missbrauch, privilegierte Aktionen und Missbrauch von Servicekonten. Im Netzwerk stehen C2-Muster, laterale Bewegung, DNS-Auffälligkeiten und Datenabfluss im Fokus. In der Cloud kommen Fehlkonfigurationen, ungewöhnliche API-Nutzung, Schlüsselmissbrauch und verdächtige Rollenwechsel hinzu.

Ein starker Endpoint-Use-Case ist die Erkennung von Living-off-the-Land-Techniken. Statt nur auf bekannte Malware zu schauen, wird auf legitime Werkzeuge mit atypischer Nutzung geachtet: rundll32, regsvr32, mshta, certutil, powershell, wmic. Die Detection wird deutlich besser, wenn Parent-Prozess, Benutzerkontext, Signaturstatus, Netzwerkfolgeaktivität und Host-Rolle einbezogen werden. Das ist robuster als reine Prozessnamenlisten und passt gut zu Endpoint Security Edr.

Im Identity-Bereich ist Passwort-Spraying ein klassischer Use Case. Gute Erkennung betrachtet nicht nur Fehlversuche, sondern die Verteilung über viele Konten, geringe Frequenz pro Konto, Quellwechsel, Erfolg nach Fehlversuchen und Unterschiede zwischen internen und externen Quellen. Servicekonten, SSO-Fehler und Legacy-Protokolle müssen gesondert behandelt werden. Wer nur auf Account-Lockouts schaut, erkennt viele langsame Angriffe nicht.

Im Netzwerk ist DNS oft unterschätzt. Ein Use Case auf seltene Domains, hohe Entropie, neu beobachtete Subdomains, NXDOMAIN-Muster und Korrelation mit Prozess- oder Proxy-Daten kann frühe Hinweise auf Malware oder C2 liefern. Reine DNS-Anomalie ohne Kontext ist jedoch zu schwach. Erst die Verbindung mit Endpunktdaten macht daraus eine belastbare Detection. Genau deshalb sollten Netzwerk- und Endpoint-Teams nicht getrennt arbeiten.

In Cloud-Umgebungen sind API-Aktivitäten zentral. Ein Use Case kann etwa ungewöhnliche IAM-Änderungen, das Erzeugen neuer Access Keys, das Deaktivieren von Logging oder den Zugriff auf Storage aus neuen Regionen erkennen. Besonders kritisch sind Sequenzen wie: neue Rolle erstellt, Policy erweitert, Schlüssel erzeugt, Storage aufgelistet, große Datenmengen gelesen. Solche Ketten sind wesentlich aussagekräftiger als einzelne Admin-Events. Die Verbindung zu Cloud Security Logging, Cloud Security Iam und Cloud Security Detection ist dabei direkt operativ relevant.

Ein weiterer wertvoller Use Case ist Missbrauch interner APIs. Hier helfen Korrelationen aus Authentisierung, Rate-Mustern, Fehlercodes, ungewöhnlichen Endpunkten und Datenvolumen. Besonders bei Machine-to-Machine-Kommunikation sind normale Benutzer-Baselines wenig hilfreich. Stattdessen müssen Serviceidentitäten, Deployment-Zeitpunkte und bekannte Integrationen berücksichtigt werden. In solchen Szenarien überschneidet sich Use Case Engineering mit It Security API Rate Limiting.

Praxisreife Use Cases zeichnen sich dadurch aus, dass sie nicht nur „verdächtig“ melden, sondern bereits die wahrscheinlichste Missbrauchshypothese mitliefern. Das spart Zeit in der Analyse und verbessert die Reaktionsqualität erheblich.

Use Case Engineering ist kein Projekt mit Enddatum, sondern ein laufender Verbesserungsprozess. Bedrohungen ändern sich, Infrastrukturen wachsen, Anwendungen werden umgebaut und legitimes Verhalten verschiebt sich. Deshalb müssen Use Cases regelmäßig überprüft, getestet und neu priorisiert werden. Ohne Messbarkeit bleibt diese Arbeit jedoch subjektiv.

Sinnvolle Kennzahlen orientieren sich an Wirksamkeit und Betrieb. Dazu gehören Abdeckung kritischer TTPs, Anteil produktiver Use Cases mit dokumentierten Tests, Präzision pro Use Case, mittlere Zeit bis zur Triage, mittlere Zeit bis zur Eskalation, Anteil veralteter Ausnahmen, Datenqualitätsfehler pro Quelle und Anteil von Incidents, die durch bestehende Detection erkannt wurden. Diese Kennzahlen zeigen, ob das Programm reift oder nur mehr Regeln produziert.

Wichtig ist auch die Bewertung der Use Cases nach Reifegrad. Ein neuer Use Case startet oft als experimentell. Danach folgt Pilotbetrieb mit enger Beobachtung. Erst wenn Trefferbild, Kontext und Triage stabil sind, sollte er als produktiv gelten. Später kann er durch Automatisierung ergänzt werden, etwa durch Anreicherung, Ticketing oder Response-Aktionen. Diese Stufen helfen, Erwartungen realistisch zu halten und Änderungen kontrolliert auszurollen.

Ein reifes Team arbeitet mit festen Review-Anlässen: nach Incidents, nach Purple-Team-Übungen, nach größeren Infrastrukturänderungen, nach neuen Bedrohungsinformationen und in regelmäßigen Intervallen. Besonders wertvoll sind kontrollierte Simulationen. Wenn ein Use Case nur auf Papier gut aussieht, aber bei realistischen Tests nicht auslöst, ist seine Existenz wertlos. Die Verbindung zu Pentesting Purple Team, It Security Threat Hunting und It Security Mitre Attack ist hier sehr eng.

Kontinuierliche Verbesserung bedeutet außerdem, Detection nicht isoliert zu betrachten. Wenn ein Use Case regelmäßig auf fehlende Logs stößt, ist das ein Plattformproblem. Wenn Analysten Alarme nicht einordnen können, ist das ein Kontextproblem. Wenn Reaktionen zu langsam sind, ist das ein Prozessproblem. Gute Teams behandeln diese Ursachen getrennt und verbessern nicht blind nur die Query.

Am Ende zeigt sich Qualität daran, ob Use Cases echte Entscheidungen beschleunigen. Eine gute Detection reduziert Suchraum, priorisiert sauber, liefert Kontext und führt zu reproduzierbaren Reaktionen. Genau das ist der Unterschied zwischen einem Regelkatalog und einem belastbaren Detection-Programm innerhalb moderner It Security Defense.