Kurz gesagt

  • Logs ohne Zuständigkeit und Alarmweg schaffen keine Sicherheit.
  • Beginnen Sie mit Identitäten, Administratoraktionen, Endpunkten, Backups und externer Erreichbarkeit.
  • Jeder Alarm braucht Kontext, Verantwortliche und eine erwartete Reaktionszeit.

Viele Betriebe sammeln mehr Protokolle, als irgendjemand sinnvoll prüfen kann. Gutes Monitoring beginnt deshalb nicht mit Datenmenge, sondern mit einer konkreten Frage: Welches Ereignis muss wer wie schnell erkennen, damit Schaden begrenzt werden kann? Der Angreifer liest Ihre Protokolle übrigens gründlicher als Sie. Zumindest bis heute.

Die ersten fünf Signalquellen

Priorisieren Sie Anmeldungen und MFA-Änderungen, neue Administratoren, Endpunktalarme, fehlgeschlagene Backups sowie Veränderungen an extern erreichbaren Diensten. Diese Signale decken viele realistische Angriffs- und Ausfallszenarien ab.

Konkret lohnt sich ein Blick auf Anmelde- und Audit-Logs des Identitätsanbieters, auf Anmeldeversuche an VPN und Firewall, auf Alarme der Endpunktschutzsoftware, auf das Ergebnis der Backup-Jobs sowie auf Änderungen an DNS und Zertifikaten. Blockierte Verbindungen an Zonengrenzen zeigen zusätzlich, wo ungewollte Kommunikation versucht wird.

Für Cloud-Dienste sollten Audit-Logs ausreichend lange verfügbar sein. Eine Lizenz, die Logs nur wenige Tage hält, kann die spätere Aufklärung begrenzen. Als Startwert haben sich 90 Tage für Identitäts- und Administrationslogs etabliert; längere Aufbewahrung verbessert die Forensik, erhöht aber den Speicher- und Schutzaufwand.

Alarme mit Inhalt definieren

Ein Alarm braucht System, Benutzer, Zeitpunkt, betroffene Ressource und eine erste Handlungsempfehlung. Wiederkehrende Fehlalarme werden angepasst. Dauerhaft ignorierte Warnungen sind ein Prozessfehler, kein normales Hintergrundrauschen. Definieren Sie Bereitschaft realistisch: Wenn nachts niemand reagiert, darf ein Konzept keine 24-Stunden-Reaktion behaupten.

Bewährte kleine Regeln sind unter anderem: einer bestehenden Rolle wird ein Administrator hinzugefügt, eine MFA-Methode wird neu registriert, ein Postfach erhält eine Weiterleitungsregel, ein Backup-Job wird deaktiviert oder ein Schutzagent meldet sich ab. Solche Änderungen sind selten Betriebsnormalität, aber übliche Schritte nach einer Kompromittierung.

Zentrale Sammlung und saubere Zeit

Sammeln Sie die Logs mindestens der genannten Quellen an einem zentralen Ort, etwa einem Syslog-Server oder einem kleinen Log-Dienst. Ohne zentrale Sammlung endet Auswertung darin, dass einzelne Geräte nach einem Vorfall mühsam einzeln durchsucht werden.

Alle Quellen müssen gegen dieselbe Zeitquelle synchronisiert sein, üblicherweise über NTP. Weichen Uhrzeiten zwischen Systemen ab, lassen sich Ereignisketten nicht korrekt rekonstruieren.

Logs enthalten personenbezogene Daten und persönliche Handlungsspuren. Begrenzen Sie den Zugriff auf die verantwortlichen Personen, dokumentieren Sie Aufbewahrungsfristen und löschen Sie abgelaufene Bestände regulär.

Monatliche Betriebsroutine

Prüfen Sie monatlich Abdeckung, Datenquellen, offene Alarme und die Erreichbarkeit der Kontakte. Ein kurzer Testalarm zeigt, ob Benachrichtigung und Zuständigkeit tatsächlich funktionieren.

Konkrete nächste Schritte

  1. Fünf kritische Signale und deren Eigentümer festlegen.
  2. Zentrale Logsammlung mit synchronisierten Uhrzeiten einrichten.
  3. Aufbewahrungsdauer der wichtigsten Logs prüfen.
  4. Alarmwege und erreichbare Kontakte dokumentieren.
  5. Einen Testalarm auslösen und bis zum Abschluss verfolgen.

vetosec bietet Monitoring und technische Betreuung dort an, wo ein klarer Betriebsumfang vereinbart ist. Ein SIEM ist nicht automatisch notwendig, wenn wenige Quellen sauber überwacht und ihre Alarme tatsächlich bearbeitet werden.

Passende Inhalte von vetosec

Primärquellen