Ihr SIEM löst täglich 500 „Anmeldefehler“-Alarme aus, fast alles Rauschen, und die Analysten ignorieren die Regel inzwischen. Was ist der richtige Schritt?
Kurzantwort
Reduzieren Sie Fehlalarme durch Detection Engineering, nicht indem Sie sich blind machen. Passen Sie die Regel neu an, sodass Alarme nur bei relevanten Mustern auslösen — ein Passwort gegen viele Konten (Spraying), ein Konto vielfach angegriffen (Stuffing/Brute Force), unmögliche Reise — während die Rohereignisse auf einem Dashboard durchsuchbar bleiben. Messen Sie dann die Alarmpräzision über die Zeit. Die Regel zu deaktivieren entfernt ein echtes Signal, eine pauschale Unterdrückung schafft einen dauerhaften blinden Fleck, und Leute für die Triage von reinem Rauschen einzustellen skaliert nicht und brennt sie aus.
Eine Regel, die täglich 500-mal auslöst und ignoriert wird, ist schlimmer als gar keine Regel — sie trainiert Analysten darauf, genau die Ereigniskategorie abzutun, die zählt, und der echte Angriff verbirgt sich im Rauschen. Diese Frage prüft, ob Sie zu Detection Engineering greifen statt zu den beiden bequemen Extremen: abschalten oder Personal auf das Problem werfen.
Warum Tuning die Antwort ist
Anmeldefehler sind an sich nicht interessant; die Muster von Fehlern sind es. Bauen Sie die Erkennung so um, dass sie nur bei Signal alarmiert:
- Password Spraying — ein Passwort gegen viele Konten in einem kurzen Fenster getestet.
- Credential Stuffing / Brute Force — viele Fehlversuche gegen ein einzelnes Konto oder ein Stoß von einer Quell-IP.
- Unmögliche Reise oder ein fehlgeschlagener Login unmittelbar gefolgt von einem Erfolg aus einer neuen Geo/ASN.
Entscheidend: Sie behalten die Rohereignisse in einem durchsuchbaren Index oder Dashboard — nur eben nicht als Alarme. Das bewahrt die Daten für die Jagd und die nachträgliche Eingrenzung, während es das Rauschen pro Ereignis entfernt. Dann messen Sie die Präzision (echte Positive / Gesamtalarme), um zu belegen, dass das Tuning funktioniert hat, und es weiter zu verfeinern.
Warum die anderen Optionen scheitern
- Die Regel deaktivieren — Sie löschen das Signal vollständig. Brute Force und Spraying sind verbreitete Techniken für den Erstzugang; dort blind zu werden ist ein Geschenk an Angreifer.
- Alle unterdrücken und auf EDR vertrauen — das EDR überwacht Endgeräte, nicht Ihren Identitätsanbieter oder Ihre Cloud-Auth-Oberfläche. Ein Spraying gegen ein VPN oder M365-Portal berührt vielleicht nie einen EDR-überwachten Host. Das ist ein blinder Fleck, keine Strategie.
- Mehr Analysten einstellen — Menschen dafür zu bezahlen, Rauschen abzutun, behebt nicht das kaputte Signal-Rausch-Verhältnis; es verteilt nur die Müdigkeit und skaliert nicht mit dem Volumen.
Was der Interviewer prüft
Er will einen Kandidaten, der das SOC als Ingenieursproblem behandelt: Fehlalarme sind ein anpassbarer Defekt, keine Naturgegebenheit. Die starke Antwort benennt die zu erkennenden Angriffsmuster, bewahrt die Rohdaten für die Untersuchung und verpflichtet sich, die Präzision über die Zeit zu messen — der Unterschied zwischen einem Analysten, der Alarme erträgt, und einem, der die Erkennung verbessert.
Wahrscheinliche Anschlussfragen
- Welche Schwellenwerte unterscheiden Password Spraying von Credential Stuffing in Ihrer Erkennungslogik?
- Wie würden Sie messen, ob Ihre Anpassung die Präzision verbessert hat, ohne einen echten Angriff durchzulassen?
- Wie halten Sie die Rohdaten für die Jagd verfügbar, ohne dass sie Alarme erzeugen?