Führ mich durch deine Triage eines Security-Alerts, ab dem Moment, in dem er in deiner Queue landet.

Fang damit an zu bestätigen, worauf die Detection tatsächlich gefeuert hat, und reicher an, bevor du urteilst. Zieh das Rohlog, identifizier Host, User, Prozess und Netzwerkkontext, und prüf die Kritikalität des Assets. Vergleich mit bekanntem Normalverhalten und aktuellen Change-Tickets. Entscheide True Positive, False Positive oder Benign True Positive, dokumentier die Begründung, und schließ entweder mit Tuning-Feedback oder eskalier mit einer Zeitleiste.

Das Erste, was ich mache, ist die Rule-Logik lesen, nicht nur den Alert-Titel, denn der Titel ist oft veraltet. Dann reichere ich an: Host, User, Eltern- und Kindprozess, Command Line, Ziel-IP und deren Reputation, und ob der User ein offenes Change-Ticket hat. An meiner letzten Stelle hatte ich einen Alert für encoded PowerShell auf einer Finanz-Workstation. Die Command Line dekodierte zu einem Blob, der sich als legitimer Vendor-Installer herausstellte, aber der Elternprozess war Outlook, und genau dieses Muster interessiert mich, ich habe also nicht dort abgeschlossen. Ich habe das Postfach geprüft, gefunden, dass die Nachricht von einer bekannten Lieferantendomain mit gültiger Signatur kam, und beim User telefonisch statt per E-Mail bestätigt, falls sein Account übernommen war. Benign True Positive. Ich habe es aufgeschrieben und dann dem Detection Engineer vorgeschlagen, genau diesen Vendor-Hash auszunehmen statt der ganzen Regel für encoded PowerShell, was uns blind gemacht hätte.