Eine Regel erzeugt hunderte Alerts pro Tag. Wie tunst du sie, ohne einen blinden Fleck zu schaffen?

Analysier das Rauschen, bevor du die Regel anfasst. Gruppier die Alerts nach Host, User, Prozess und Command Line, um die wenigen Quellen zu finden, die das meiste Volumen erzeugen, und schreib dann enge Ausnahmen, die auf dauerhaften Attributen keyen, etwa ein signierter Binary-Pfad plus ein bestimmter Elternprozess, nicht eine breite Wildcard. Halt die unterdrückten Events durchsuchbar, setz ein Ablaufdatum für die Überprüfung, und dokumentier das Restrisiko, das du akzeptiert hast.

Zuerst ziehe ich dreißig Tage dieser Regel und gruppiere die Treffer. Meistens kommen achtzig Prozent aus drei Quellen. In einem Job hat uns eine certutil-Regel ertränkt, und es stellte sich heraus, dass ein Software-Deployment-Agent bei jeder Installation certutil aufrief, um eine Zertifikatskette zu prüfen. Meine Ausnahme war nicht certutil. Sie war dieser bestimmte Elternprozess, aus diesem Installationspfad, laufend unter dem Deployment-Service-Konto. Alles andere, was certutil aufrief, alarmierte weiterhin. Ich habe die Events außerdem mit abgeschaltetem Alerting weiter in den Data Lake fließen lassen, damit die Historie da ist, falls wir später darüber jagen müssen. Dann habe ich eine Neunzig-Tage-Prüfung auf die Ausnahme gesetzt und im Change Record eine Zeile geschrieben, was ein Angreifer kontrollieren müsste, um sie zu missbrauchen, hier also den Deployment-Server zu kompromittieren, und auf dieser Kiste hatten wir bereits getrenntes Monitoring. Das Volumen ging von grob vierhundert am Tag auf unter zehn, und wir haben die Technik nicht verloren.