Detections testen und abstimmen

Eine nicht abgestimmte Detektion, die bei harmloser Aktivität auslöst, ist schlimmer als keine Detektion. Analysten lernen, laute Warnungen zu ignorieren, und der eine echte Angriff geht in der Warteschlange unter. Das ist Alert Fatigue, und so bleiben Angriffe selbst an gut ausgestatteten SOCs unentdeckt.

Tuning ist der disziplinierte Prozess, echte Treffer zu maximieren und gleichzeitig Fehlalarme gegen null zu bringen, ohne sich für tatsächliche Bedrohungen blind zu machen.

Qualität der Frame-Erkennung anhand von vier Ergebnissen:

• Richtig-positiv (TP) — löst bei tatsächlich bösartiger Aktivität aus
• Falsch-positiv (FP) — löst bei legitimer Aktivität aus
• Richtig-negativ (TN) — bleibt bei legitimer Aktivität korrekt stumm
• Falsch-negativ (FN) — übersieht tatsächlich bösartige Aktivität

Beim Tuning bewegt man sich in diesem Spannungsfeld. Wird eine Regel gelockert, sinkt die Zahl der FNs, aber das Risiko für FPs steigt; eine Verschärfung bewirkt das Gegenteil. Die Kunst besteht darin, das Gleichgewicht zu finden, das das SOC dauerhaft bewältigen kann.

Sie können nicht blind tunen. Erstellen Sie eine Sammlung aus bekannt-bösartigen Beispielen (die Regel muss auslösen) und bekannt-guten Beispielen (die Regel muss stumm bleiben). In Sigma DaC liegen diese als Testfälle neben der Regel.

Erzeugen Sie echte Telemetriedaten aus bekannt-bösartigen Aktivitäten, indem Sie die Technik sicher ausführen. Atomic Red Team stellt kleine, dokumentierte, ATT&CK zugeordnete Tests bereit, die Sie in einer Laborumgebung ausführen, um zu bestätigen, dass Ihre Regel tatsächlich auslöst.

Führen Sie den Atomic-Test aus, erfassen Sie die Logs und prüfen Sie, dass die Erkennung auslöst. Falls dies nicht geschieht, weist Ihre Regel eine Abdeckungslücke auf – unabhängig davon, wie gut das YAML aussieht.

Bevor Sie eine Regel zum Auslösen von Alerts bereitstellen, führen Sie sie im Audit-Modus mit historischen und Live-Daten aus, um zu ermitteln, was sie normalerweise auslöst. Diese Baseline zeigt die legitimen Prozesse, Administratoren und Tools, die andernfalls FPs erzeugen würden.

Was abstrakt bösartig aussieht, ist in Ihrer konkreten Umgebung oft ein Backup-Job, ein Schwachstellen-Scanner oder ein RMM-Agent. Durch die Baseline-Erstellung werden diese Aktivitäten sichtbar, bevor sie nachts einen Analysten wecken.

Beim saubersten Tuning bleibt die bösartige Logik intakt, während bekannte legitime Auslöser durch explizite Filter ausgenommen werden. Das ist auditierbar: Eine prüfende Person sieht genau, was ausgeschlossen wurde und warum.

Bevorzugen Sie enge, begründete Ausschlüsse gegenüber einer Erweiterung der Kernlogik, durch die unbemerkt blinde Flecken entstehen können.

Jeder Ausschluss ist eine Lücke, in der sich ein Angreifer verstecken kann. Wenn Sie sämtliche Aktivitäten aus ParentImage herausfiltern, die einen Toolnamen enthalten, kann ein Angreifer, der sich unter diesem Namen tarnt, Ihre Erkennung umgehen.

Richtlinien:

• Filtern Sie nach dem spezifischsten verfügbaren Attribut (vollständiger Pfad, signierter Herausgeber, Hash)
• Dokumentieren Sie, warum jeder Filter existiert
• Prüfen Sie Filter regelmäßig erneut — Umgebungen ändern sich
• Erhöhen Sie vorzugsweise einen Schwellenwert, statt eine Bedingung zu entfernen

Manche Verhaltensweisen sind erst ab einer bestimmten Menge verdächtig. Eine einzelne fehlgeschlagene Anmeldung ist normal; fünfzig innerhalb einer Minute von einer Quelle sind es nicht. Verwenden Sie in der Bedingung eine Aggregation, um bei einer Rate oder Anzahl statt bei jedem einzelnen Ereignis einen Alert auszulösen.

Das Tuning von Schwellenwerten reduziert das Rauschen bei Brute-Force-, Scan- und Exfiltrationsmustern erheblich.

Tuning ist kontinuierlich, nicht einmalig. Erfassen Sie Metriken pro Regel und nehmen Sie die problematischsten Regeln erneut in Angriff:

• Alert-Volumen pro Regel und Tag
• FP-Rate anhand der Einstufungen durch Analysten
• Precision = TP / (TP + FP)
• Auswirkungen auf die Zeit bis zur Triage

Eine Regel, die 200 Alerts pro Woche erzeugt, die allesamt als legitim geschlossen werden, sollte getunt, in den Audit-Modus zurückgestuft oder außer Betrieb genommen werden. Lassen Sie die Daten die Entscheidung bestimmen.

Nicht jedes Rauschen lässt sich durch Unterdrückung beheben. Oft ist ein Alert technisch korrekt, benötigt aber Kontext für seine Einordnung. Enrichment fügt diesen Kontext automatisch hinzu, sodass Analysten schneller entscheiden.

• Kritikalität und Eigentümer des Assets
• Rolle des Benutzers und ob das Konto privilegiert ist
• Reputation aus Threat Intelligence für IPs, Domains und Hashes
• Ob sich der Host in einem Wartungsfenster befindet

Angereicherte Alerts ermöglichen eine Risikobewertung und Priorisierung und reduzieren das effektive Rauschen, selbst wenn sich das reine Alert-Volumen nicht verändert.

Wenn Sie eine Regel tunen, führen Sie ihre vollständige Testsuite erneut in CI aus. Die bekannt-bösartigen Tests verhindern, dass Sie versehentlich echte Erkennungen wegstimmen; die bekannt-guten Tests bestätigen, dass der FP behoben wurde.

Dieser geschlossene Regelkreis erklärt, warum DaC und Tuning zusammengehören: Sie können Regeln aggressiv umstrukturieren, weil die Tests jede dadurch beschädigte Abdeckung erkennen.

Tuning hält Erkennungen vertrauenswürdig und umsetzbar:

• Unkontrollierte FPs führen zu Alert-Müdigkeit und übersehenen Sicherheitsverletzungen
• Beurteilen Sie sie anhand des TP/FP/TN/FN-Rahmens
• Erstellen Sie bekannt-gute und bekannt-bösartige Testsammlungen
• Verwenden Sie Simulationen von Angreiferaktivitäten (Atomic Red Team), um nachzuweisen, dass Regeln auslösen
• Erstellen Sie vor dem Alerting eine Baseline im Audit-Modus
• Tunen Sie mit engen, dokumentierten Filtern und Schwellenwerten, nicht mit weitreichenden Ausschlüssen
• Messen Sie FP-Rate und Precision und iterieren Sie bei den problematischsten Regeln
• Führen Sie bei jeder Änderung Regressionstests erneut aus

Sie haben den Sigma-Kurs zum Detection Engineering abgeschlossen.