SIEM & SOC: Use Cases, Logquellen und Retention vor der Plattformwahl
Ein SIEM erzeugt nicht automatisch Detection. Nutzen entsteht erst aus priorisierten Angriffsszenarien, belastbaren Logquellen, Zeitstempeln, Datenqualität, Regeln, Triage, Eskalation und einer Retention, die technisch wie wirtschaftlich tragfähig ist.
Mit Angriffsszenarien statt mit Logmengen beginnen
Ein belastbarer Startpunkt sind wenige priorisierte Szenarien wie kompromittierte Admin-Konten, verdächtige Remote-Zugriffe, Malware-Ausbreitung oder ungewöhnliche Massenänderungen. Erst daraus wird abgeleitet, welche Quellen, Felder und Zeitbezüge tatsächlich benötigt werden.
Datenqualität ist ein eigener Betriebsprozess
Fehlende Events, falsche Zeitzonen, wechselnde Feldnamen und unterbrochene Connectoren können Detection still entwerten. Für kritische Quellen gehören Ingestion-Status, Parserqualität und erwartete Ereignisraten in das Monitoring.
Retention folgt Use Case und Nachweisbedarf
Nicht jedes Event muss gleich lange im teuren Analyse-Tier liegen. Hot- und Long-Term-Retention sollten nach Detection, Forensik, Nachweisbedarf und Kosten getrennt geplant werden. Eine pauschale maximale Aufbewahrung erzeugt sonst hohe Kosten ohne proportionalen Sicherheitsnutzen.
SOC ist Rolle und Prozess, nicht nur Oberfläche
Alarmpriorisierung, Triage, Eskalation, Bereitschaft, Incident-Verantwortung und Übergabe an IT-Betrieb müssen festgelegt sein. Automatisierung oder SOAR darf klare Freigabegrenzen unterstützen, nicht unklare Zuständigkeiten verdecken.
Pilot anhand messbarer Detection testen
Ein Pilot sollte definierte Testereignisse erzeugen und messen, ob sie vollständig ankommen, korrekt korreliert werden, einen verständlichen Alarm erzeugen und innerhalb einer Zielzeit bearbeitet werden können.