Logging und Monitoring: Was du protokollieren solltest und warum

Warum Logging und Monitoring keine optionalen Extras sind

Ein mittelständisches Unternehmen mit 120 Mitarbeitern hat an einem Freitagabend einen Ransomware-Angriff erlitten. Am Montagmorgen war klar, dass die Angreifer bereits seit drei Wochen im Netzwerk waren. Sie hatten sich lateral bewegt, Daten exfiltriert und schließlich die Verschlüsselung ausgelöst. Die IT-Abteilung wollte nachvollziehen, wie der Angriff abgelaufen war, welche Systeme betroffen waren und welche Daten abgeflossen sind. Die Antwort auf all diese Fragen war dieselbe: Wir wissen es nicht. Die Logs waren lokal auf den einzelnen Servern gespeichert, und die Server waren verschlüsselt. Selbst die wenigen Logs, die noch zugänglich waren, reichten nur 48 Stunden zurück, weil die Standard-Aufbewahrungsfrist des Windows Event Logs nie angepasst worden war.

Das BSI berichtet regelmäßig, dass fehlende Protokollierung bei der Aufarbeitung von Cybervorfällen eines der größten Hindernisse darstellt. Man weiß, dass etwas passiert ist, aber man kann nicht rekonstruieren, was genau, wann und über welchen Weg.

Logging ist die Grundlage für Incident Response, Forensik und Behördenmeldungen. Monitoring geht einen Schritt weiter und versucht, Vorfälle zu erkennen, bevor sie eskalieren.

ISO 27001 fordert in Annex A.8.15 (Logging) und A.8.16 (Monitoring activities) explizit, dass sicherheitsrelevante Ereignisse protokolliert, die Logs geschützt und regelmäßig ausgewertet werden. NIS2 verschärft diese Anforderungen nochmals und verlangt in Artikel 21 die Fähigkeit, Sicherheitsvorfälle zu erkennen und darauf zu reagieren, was ohne funktionierendes Logging und Monitoring schlicht unmöglich ist.

Was du protokollieren solltest: Die fünf Log-Kategorien

Die Antwort „alles" klingt verlockend, führt aber in die Sackgasse: zu viel Rauschen, explodierende Speicherkosten. Die bessere Antwort orientiert sich an fünf Kategorien, die zusammen ein solides Fundament bilden.

Kategorie 1: Authentifizierung

Jeder Anmeldeversuch in deiner Umgebung sollte protokolliert werden, erfolgreich und gescheitert. Das umfasst:

• Anmeldungen an Windows-Domänen (Active Directory)
• Anmeldungen an VPN und Remote-Desktop-Diensten
• Anmeldungen an Webanwendungen (ERP, CRM, E-Mail-Webzugang, Cloud-Dienste)
• Anmeldungen an Netzwerkgeräten (Firewalls, Switches, WLAN-Controller)
• Passwortänderungen und Passwortzurücksetzungen
• MFA-Ereignisse (erfolgreiche und abgelehnte zweite Faktoren)

Authentifizierungslogs sind die erste Verteidigungslinie. Brute Force zeigt sich durch massenhafte Fehlversuche, Password Spraying durch vereinzelte Fehlversuche über viele Accounts, und kompromittierte Accounts durch Anmeldungen zu ungewöhnlichen Zeiten oder Standorten.

Auf einem Windows Domain Controller sind die relevanten Event-IDs:

Kategorie 2: Zugriffe auf kritische Daten und Systeme

Nicht jeder Dateizugriff muss protokolliert werden, das wäre bei einem Fileserver mit Millionen von Dateien weder praktikabel noch sinnvoll. Aber der Zugriff auf besonders schützenswerte Daten und Systeme schon.

Dazu gehören:

• Zugriffe auf Personalakten, Gehaltsdaten und Geschäftsführungsdokumente
• Zugriffe auf Finanzdaten und Buchhaltungssysteme
• Zugriffe auf Kundendatenbanken mit personenbezogenen Daten
• Zugriffe auf technische Dokumentation und Geschäftsgeheimnisse
• Zugriffe auf Backup-Systeme und deren Konfiguration
• Zugriffe auf Active Directory (LDAP-Abfragen, insbesondere für privilegierte Objekte)

Die Technik dafür ist in Windows-Umgebungen die Objektzugriffsüberwachung (Object Access Auditing), die du per GPO aktivierst und auf konkreten Ordnern konfigurierst. Für besonders schützenswerte Daten empfiehlt sich die Überwachung von Lese- und Schreibzugriffen, für weniger kritische Bereiche reichen Schreibzugriffe und Löschungen.

Auf Datenbankebene bieten die meisten Systeme eigene Audit-Funktionen (SQL Server Audit, pgAudit, MySQL Enterprise Audit). Aktiviere sie mindestens für DDL-Befehle, Zugriffe auf sensitive Tabellen und Schema-Änderungen.

Kategorie 3: Administrative Änderungen

Jede Änderung an der Konfiguration deiner IT-Umgebung muss nachvollziehbar sein. Das ist nicht nur eine Sicherheitsanforderung, sondern auch operativ sinnvoll, denn wenn nach einer Änderung etwas nicht mehr funktioniert, musst du wissen, was geändert wurde.

Protokolliere mindestens:

• Benutzer- und Gruppenverwaltung in Active Directory (Anlage, Änderung, Löschung, Gruppenmitgliedschaften)
• GPO-Änderungen (Erstellung, Bearbeitung, Verknüpfung, Löschung)
• Firewall-Regeländerungen
• DNS-Änderungen
• DHCP-Konfigurationsänderungen
• Änderungen an Backup-Jobs und -Zeitplänen
• Software-Installationen auf Servern
• Änderungen an Berechtigungen auf Dateifreigaben
• Konfigurationsänderungen an Netzwerkgeräten

In Active Directory sind die relevanten Event-IDs:

Kategorie 4: Netzwerkverkehr

Du musst nicht jeden einzelnen Netzwerk-Frame protokollieren, das wäre bei einem Unternehmensnetzwerk schlicht unmöglich. Aber du brauchst Protokolle auf zwei Ebenen: auf der Firewall-Ebene und auf der DNS-Ebene.

Firewall-Logs zeigen dir, welcher Verkehr erlaubt und welcher blockiert wurde. Besonders relevant sind ausgehende Verbindungen zu unbekannten oder ungewöhnlichen Zielen (ein Server, der plötzlich Daten an eine IP-Adresse in einem fremden Land sendet, ist ein klassisches Exfiltrations-Indiz) sowie eingehende Verbindungsversuche auf unerwarteten Ports.

DNS-Logs sind eine unterschätzte Goldmine für die Sicherheitsanalyse. Malware kommuniziert häufig über DNS mit ihren Command-and-Control-Servern. Wenn du DNS-Abfragen protokollierst, kannst du nach einem Vorfall nachvollziehen, welche Systeme mit welchen Domains kommuniziert haben. Ein Arbeitsplatz, der innerhalb von Minuten Hunderte unterschiedlicher Subdomains einer unbekannten Domain abfragt, ist mit hoher Wahrscheinlichkeit kompromittiert.

DHCP-Logs helfen dir, IP-Adressen zu Rechnernamen und damit zu Benutzern zuzuordnen. VPN-Logs zeigen, wer sich von außen verbunden hat, wann und wie lange.

Kategorie 5: Anwendungsfehler und Systemereignisse

Die letzte Kategorie umfasst Ereignisse, die nicht direkt sicherheitsrelevant erscheinen, es aber oft sind: Anwendungsabstürze, Dienstausfälle, Ressourcenerschöpfung. Viele Angriffstechniken hinterlassen Spuren in Form von Anwendungsfehlern. Ein Buffer-Overflow-Exploit führt zum Absturz des angegriffenen Dienstes, Malware-Injection macht Prozesse instabil.

Relevante Windows-Event-IDs in dieser Kategorie:

Event ID 1102 verdient besondere Aufmerksamkeit: Wenn jemand das Security Event Log löscht, ist das in einer Produktivumgebung praktisch nie ein legitimer Vorgang. Es ist fast immer ein Versuch, Spuren zu verwischen. Ein Alarm auf diese Event-ID ist ein Muss.

Wo speichern: Zentrales Log-Management

Logs, die nur lokal auf den einzelnen Systemen liegen, haben zwei fundamentale Probleme: Bei einer Kompromittierung sind sie weg, und bei einem Vorfall über mehrere Systeme hinweg ist die dezentrale Analyse viel zu langsam.

Die Lösung ist ein zentrales Log-Management-System: ein dedizierter Server, an den alle Systeme ihre Logs senden und der sie durchsuchbar vorhält.

SIEM-Alternativen für KMU

Das Akronym SIEM (Security Information and Event Management) steht für die Königsklasse des Log-Managements: Systeme, die Logs aus verschiedenen Quellen korrelieren, Regeln anwenden und Alarme auslösen. Enterprise-SIEMs wie Splunk, QRadar oder Microsoft Sentinel sind leistungsfähig, aber für ein Unternehmen mit 100 Mitarbeitern oft weder finanziell noch personell darstellbar. Die Lizenzkosten liegen schnell im fünfstelligen Bereich pro Jahr, und der Betrieb erfordert dediziertes Know-how.

Die gute Nachricht: Es gibt Alternativen, die für KMU realistisch sind.

Wazuh ist eine Open-Source-Plattform, die Endpoint-Monitoring, Log-Analyse und SIEM-Funktionalität kombiniert. Wazuh sammelt Logs über Agenten auf Windows- und Linux-Systemen, speichert sie zentral und bietet vordefinierte Regeln für die Erkennung gängiger Angriffsmuster. Für 100 Endpunkte brauchst du einen Server mit 8 GB RAM und 500 GB Festplatte, also überschaubare Hardware-Anforderungen.

Graylog Open eignet sich besonders gut, wenn du primär Logs sammeln, durchsuchen und auswerten willst, ohne den vollen SIEM-Funktionsumfang zu benötigen. Die Oberfläche ist intuitiver als die von Wazuh und die Einrichtung weniger komplex.

Windows Event Forwarding (WEF) ist die niedrigschwelligste Option und bereits in Windows enthalten. Du konfigurierst einen Windows-Server als Collector, und alle anderen Systeme leiten ihre relevanten Events dorthin weiter. WEF hat eingeschränkte Such- und Alarmierungsfunktionen, eignet sich aber als Einstiegslösung.

Elastic Stack (ELK) mit Elasticsearch, Logstash und Kibana ist mächtig und flexibel, erfordert aber mehr technisches Know-how für Einrichtung und Betrieb.

Empfehlung für den Einstieg: Starte mit Windows Event Forwarding, um die wichtigsten Windows-Events zentral zu sammeln. Wenn du merkst, dass du mehr Analyse- und Alarmierungsfunktionen brauchst, migriere auf Wazuh oder Graylog. Der Übergang ist fließend, weil alle diese Systeme die gleichen Log-Formate verarbeiten.

Architektur und Absicherung

Unabhängig von der gewählten Lösung gelten einige Grundprinzipien für die Architektur:

Netzwerksegmentierung. Der Log-Server gehört in ein eigenes Netzsegment oder zumindest in ein Segment, das nicht direkt vom gleichen Netzwerk wie die Arbeitsplätze erreichbar ist. Ein Angreifer, der einen Arbeitsplatz kompromittiert, sollte nicht trivial auf den Log-Server zugreifen können.

Schreibzugriff, kein Löschen. Systeme, die Logs senden, dürfen auf dem Log-Server nur schreiben, nicht lesen oder löschen. Das verhindert, dass ein kompromittiertes System seine eigenen Logs auf dem zentralen Server manipuliert.

Eigene Authentifizierung. Der Log-Server sollte idealerweise nicht in die Active-Directory-Domain eingebunden sein. Wenn AD kompromittiert wird, bleibt der Log-Server intakt und die Logs für die Forensik verfügbar.

Verschlüsselte Übertragung. Logs enthalten sensitive Informationen (Benutzernamen, IP-Adressen, teilweise Ressourcenpfade). Die Übertragung vom Quellsystem zum Log-Server muss verschlüsselt erfolgen (TLS bei Syslog, HTTPS bei API-basierten Lösungen).

Aufbewahrungsfristen definieren

Wie lange musst du Logs aufbewahren? Die Antwort hängt von drei Faktoren ab: regulatorische Anforderungen, praktische Notwendigkeit und Speicherkosten.

Regulatorische Anforderungen

ISO 27001 gibt keine feste Aufbewahrungsfrist vor, fordert aber, dass die Aufbewahrungsdauer definiert und dokumentiert ist und dass die Logs lange genug verfügbar sind, um Sicherheitsvorfälle untersuchen zu können.

NIS2 fordert die Fähigkeit zur Incident-Analyse. Da die Meldepflicht einen detaillierten Abschlussbericht innerhalb eines Monats verlangt, müssen Logs mindestens so lange verfügbar sein, dass eine vollständige Vorfallsanalyse durchgeführt werden kann. In der Praxis sind das mindestens 90 Tage, besser sechs Monate.

DSGVO begrenzt die Aufbewahrungsdauer: Logs mit personenbezogenen Daten dürfen nur so lange gespeichert werden, wie es für den Verarbeitungszweck erforderlich ist (Grundsatz der Speicherbegrenzung, Artikel 5 Abs. 1 lit. e).

BSI-Grundschutz empfiehlt in OPS.1.1.5 eine Aufbewahrungsdauer von mindestens 90 Tagen.

Handelsrechtliche Aufbewahrung kann bei bestimmten Logs (etwa Zugriffen auf Finanzsysteme) die steuerrechtliche Aufbewahrungsfrist von zehn Jahren relevant machen, wenn die Logs als geschäftsrelevante Unterlagen eingestuft werden.

Empfohlene Aufbewahrungsfristen

Für ein mittelständisches Unternehmen empfehle ich folgende Staffelung:

Die Online-Aufbewahrung bedeutet, dass die Logs auf dem Log-Server direkt durchsuchbar sind. Die Archiv-Aufbewahrung bedeutet, dass ältere Logs komprimiert auf einem Archivspeicher liegen und bei Bedarf wiederhergestellt werden können. Diese Staffelung hält die Speicherkosten im Rahmen, ohne die Analysefähigkeit zu gefährden.

Automatische Löschung. Definiere für jede Log-Kategorie eine automatische Löschfrist und setze sie technisch um. Logs, die über die definierte Aufbewahrungsfrist hinaus gespeichert werden, sind nicht nur ein Speicherproblem, sondern auch ein Datenschutzproblem.

Alarme definieren: Von Logs zu Handlungen

Logs zu sammeln ist nur die halbe Miete. Der eigentliche Wert entsteht erst, wenn du aus den Logs Alarme ableitest, also automatisierte Benachrichtigungen, die dich auf verdächtige Aktivitäten aufmerksam machen.

Der häufigste Fehler ist, zu viele Alarme zu definieren. Wenn dein IT-Team täglich 200 Alerts bekommt, davon 195 False Positives, werden alle nach kurzer Zeit ignoriert. Dieses Phänomen (Alert Fatigue) ist gefährlicher als gar keine Alerts.

Alarme für den Einstieg

Starte mit einer überschaubaren Anzahl von Alarmen, die mit hoher Wahrscheinlichkeit auf echte Probleme hinweisen:

Alarm 1: Massenhafte fehlgeschlagene Anmeldungen. Schwellwert: Mehr als 20 fehlgeschlagene Anmeldeversuche innerhalb von 5 Minuten auf einem einzelnen Account (Brute Force) oder mehr als 5 fehlgeschlagene Anmeldeversuche auf mehr als 10 verschiedenen Accounts innerhalb von 10 Minuten (Password Spraying). Benachrichtigung: IT-Sicherheitsverantwortlicher per E-Mail und Messenger. Reaktion: Account sperren (bei Brute Force), Quell-IP identifizieren und prüfen.

Alarm 2: Anmeldung eines Admin-Accounts außerhalb der Geschäftszeiten. Schwellwert: Jede erfolgreiche Anmeldung eines Tier-0- oder Tier-1-Admin-Accounts zwischen 22:00 und 06:00 Uhr oder am Wochenende. Benachrichtigung: IT-Leitung per SMS oder Messenger. Reaktion: Sofortige Verifizierung, ob die Anmeldung legitim ist.

Alarm 3: Mitglied zu einer privilegierten Gruppe hinzugefügt. Schwellwert: Jedes Hinzufügen eines Mitglieds zu Domain Admins, Enterprise Admins, Schema Admins, Administrators oder Backup Operators. Benachrichtigung: IT-Leitung und ISB per E-Mail. Reaktion: Prüfen, ob ein genehmigter Change Request vorliegt.

Alarm 4: Audit-Log gelöscht. Schwellwert: Jedes Auftreten von Event ID 1102 (Security Log was cleared). Benachrichtigung: ISB per Messenger, sofort. Reaktion: Sofortige Untersuchung, da dies fast immer auf einen Angriff hindeutet.

Alarm 5: Neuer Dienst installiert auf einem Server. Schwellwert: Jedes Auftreten von Event ID 7045 auf einem Server-System. Benachrichtigung: IT-Sicherheitsverantwortlicher per E-Mail. Reaktion: Prüfen, ob die Installation geplant und autorisiert war. Malware installiert sich häufig als Windows-Dienst.

Alarm 6: Ungewöhnlich hohe Datenübertragung. Schwellwert: Ausgehender Netzwerkverkehr eines einzelnen Systems, der das Dreifache des üblichen Tagesdurchschnitts überschreitet. Benachrichtigung: IT-Sicherheitsverantwortlicher per E-Mail. Reaktion: Prüfen auf Datenexfiltration oder kompromittiertes System.

Alarmierung strukturiert aufsetzen

Jeder Alarm braucht eine klare Definition: Name und Beschreibung, Datenquelle, Schwellwert und Zeitfenster, Empfänger, Benachrichtigungskanal, erwartete Reaktion, Eskalation bei Nicht-Reaktion und geschätzte False-Positive-Rate.

Dokumentiere diese Definitionen in deinem ISMS. Im Audit wird nicht nur gefragt, ob du Alarme hast, sondern auch, ob sie dokumentiert sind und ob du nachweisen kannst, dass Alarme tatsächlich bearbeitet werden.

Windows Event IDs, die du kennen solltest

Wenn du in einer Windows-dominierten Umgebung arbeitest, wirst du dich unweigerlich mit Windows Event IDs beschäftigen. Die folgende Zusammenstellung enthält die Event-IDs, die für Sicherheitsmonitoring am relevantesten sind, gruppiert nach Anwendungsfall.

Anmeldungen und Authentifizierung

Account- und Gruppenverwaltung

Systemsicherheit

Process Command Line Auditing

Ein besonders wertvolles Feature, das in vielen Umgebungen nicht aktiviert ist: Process Command Line Auditing. Wenn du diese Funktion per GPO aktivierst (Computer Configuration > Administrative Templates > System > Audit Process Creation > Include command line in process creation events), wird bei jedem neuen Prozess (Event ID 4688) auch die vollständige Befehlszeile protokolliert.

Das macht einen enormen Unterschied: Statt „powershell.exe wurde gestartet" siehst du „powershell.exe -enc SQBuAHYAbwBrAGUALQBXAGUAYg...", was dir sofort zeigt, dass hier ein Base64-kodierter Befehl ausgeführt wurde, ein klassisches Angriffsmuster.

Datenschutz beim Logging

Logs enthalten personenbezogene Daten. Benutzernamen, IP-Adressen, Zugriffszeitpunkte, besuchte Ressourcen: All das lässt sich einer identifizierbaren Person zuordnen. Damit unterliegt die Verarbeitung von Logs der DSGVO, und du brauchst eine saubere rechtliche Grundlage.

Rechtsgrundlage

Die gängige Rechtsgrundlage für sicherheitsbezogenes Logging ist Artikel 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse). Dein berechtigtes Interesse ist die Sicherstellung der IT-Sicherheit, die Erkennung und Aufklärung von Sicherheitsvorfällen und die Erfüllung gesetzlicher Pflichten (NIS2, ISO 27001). Dieses Interesse überwiegt in der Regel das Interesse der Betroffenen, nicht überwacht zu werden, sofern die Verarbeitung verhältnismäßig ist.

Verhältnismäßig bedeutet: Du protokollierst nur das, was für den Sicherheitszweck erforderlich ist, speicherst nicht länger als nötig, beschränkst den Zugriff und informierst die Betroffenen.

Informationspflicht

Du musst die Mitarbeiter darüber informieren, dass sicherheitsrelevante Ereignisse protokolliert werden. Die Betroffenenrechte müssen dabei gewahrt bleiben. Das gehört in die Datenschutzinformation für Beschäftigte, die typischerweise Teil des Arbeitsvertrags oder einer Betriebsvereinbarung ist.

Die Information muss enthalten: welche Daten protokolliert werden, zu welchem Zweck, auf welcher Rechtsgrundlage, wie lange aufbewahrt wird, wer Zugriff hat und welche Rechte die Betroffenen haben (Auskunft, Löschung, Beschwerde bei der Aufsichtsbehörde).

Betriebsrat

In Unternehmen mit Betriebsrat ist das Logging-Konzept mitbestimmungspflichtig nach § 87 Abs. 1 Nr. 6 BetrVG (technische Einrichtungen, die zur Überwachung geeignet sind). Du solltest den Betriebsrat frühzeitig einbinden und idealerweise eine Betriebsvereinbarung zum IT-Monitoring abschließen, die den Zweck, den Umfang und die Zugriffsbeschränkungen regelt.

Ohne Betriebsvereinbarung riskierst du, dass das gesamte Logging-System arbeitsrechtlich angreifbar wird und gewonnene Erkenntnisse nicht verwertbar sind.

Zugriffsbeschränkung

Definiere ein Berechtigungskonzept für das Log-Management-System:

• Lesezugriff auf alle Logs: Nur ISB und IT-Sicherheitsverantwortlicher
• Lesezugriff auf technische Logs: IT-Administratoren (für Fehleranalyse)
• Schreibzugriff/Administration: Nur der Log-System-Administrator
• Kein Zugriff: Personalabteilung, Geschäftsführung (es sei denn, ein konkreter, dokumentierter Anlass besteht)

Der letzte Punkt ist wichtig: Logs dürfen nicht zur allgemeinen Mitarbeiterüberwachung verwendet werden. Wenn die Geschäftsführung wissen will, wer wann an welchem Rechner gesessen hat, ist das kein Sicherheitsanlass, sondern Überwachung, und die ist ohne konkreten Verdacht und Betriebsvereinbarung nicht zulässig.

Audit-Trail für NIS2

NIS2 bringt für betroffene Unternehmen eine verschärfte Nachweispflicht. Artikel 21 fordert Maßnahmen zur Bewältigung von Sicherheitsvorfällen, und Artikel 23 fordert die Meldung erheblicher Sicherheitsvorfälle innerhalb definierter Meldefristen: eine Frühwarnung innerhalb von 24 Stunden, eine Erstbewertung innerhalb von 72 Stunden und ein Abschlussbericht innerhalb eines Monats.

Um diese Fristen einzuhalten, brauchst du einen lückenlosen Audit-Trail. Du musst nachweisen können, wann der Vorfall begonnen hat, wie er erkannt wurde, welche Systeme und Daten betroffen waren, welche Maßnahmen ergriffen wurden und ob die Meldepflichten eingehalten wurden.

Ohne zentrales Logging wird es nahezu unmöglich, innerhalb von 24 Stunden eine fundierte Frühwarnung abzugeben. Du weißt nicht, was passiert ist, seit wann es passiert und was betroffen ist.

Wenn die zuständige Aufsichtsbehörde deine NIS2-Compliance prüft, wird sie sich dein Logging-Konzept ansehen: Was wird protokolliert, wo, wie lange, wer hat Zugriff, wie werden Alarme ausgewertet? All das muss dokumentiert und nachweisbar sein.

Logging-Konzept als ISMS-Dokument

Erstelle ein Logging-Konzept als eigenständiges ISMS-Dokument mit folgenden Abschnitten. In ISMS Lite lässt sich das Logging-Konzept als Richtliniendokument mit Freigabeworkflow anlegen und die Aufbewahrungsfristen pro Log-Kategorie systematisch verwalten. Das Tool deckt alle ISMS-Module 500 Euro pro Jahr ab, ohne Seat-Lizenzen. Geltungsbereich, Log-Kategorien mit Datenquellen und Event-IDs, zentrales Log-Management (Architektur und Absicherung), Aufbewahrungsfristen pro Kategorie, Alarmregeln mit Schwellwerten und Eskalation, Zugriffskontrolle, Datenschutz (Rechtsgrundlage, Informationspflicht, Betriebsvereinbarung) und Review-Zyklus.

Dieses Dokument ist dein Nachweis gegenüber Auditoren und Aufsichtsbehörden und zeigt, dass die Logging-Strategie ein bewusst gestaltetes Element deines ISMS ist.

Von der Theorie in die Praxis: Wo anfangen?

Wenn du bisher kein systematisches Logging betreibst, kann die Menge an Anforderungen in diesem Artikel überwältigend wirken. Die gute Nachricht: Du musst nicht alles auf einmal umsetzen. Fang mit den Basics an und baue schrittweise aus.

Phase 1: Grundlagen schaffen (Woche 1-4)

• Aktiviere die erweiterten Audit-Richtlinien auf den Domain Controllern per GPO
• Erhöhe die Größe des Security Event Logs auf allen Servern (mindestens 1 GB)
• Richte Windows Event Forwarding ein, um die kritischsten Events zentral zu sammeln
• Aktiviere Process Command Line Auditing
• Dokumentiere, was du protokollierst und warum

Phase 2: Zentralisierung (Monat 2-3)

• Entscheide dich für eine Log-Management-Lösung (Wazuh, Graylog oder ELK)
• Installiere die Lösung und binde die ersten Quellen an (Domain Controller, Firewall, VPN)
• Definiere die Aufbewahrungsfristen und konfiguriere die automatische Löschung
• Binde sukzessive weitere Log-Quellen an (Dateiserver, Datenbankserver, DNS)

Phase 3: Alarmierung (Monat 3-4)

• Definiere die sechs Einstiegs-Alarme aus dem Abschnitt „Alarme definieren"
• Teste jeden Alarm gezielt (simuliere fehlgeschlagene Anmeldungen, füge einen Test-Account zu Domain Admins hinzu)
• Dokumentiere die Alarmregeln im ISMS
• Etabliere einen Prozess für die tägliche oder wöchentliche Sichtung der Alarmauswertungen

Phase 4: Optimierung (laufend)

• Werte False Positives aus und passe Schwellwerte an
• Ergänze weitere Alarmregeln basierend auf neuen Bedrohungen oder Vorfällen
• Führe regelmäßige Log-Reviews durch (mindestens monatlich)
• Überprüfe und aktualisiere das Logging-Konzept im Rahmen des jährlichen ISMS-Reviews

Logging und Monitoring sind keine Projekte, die irgendwann abgeschlossen sind. Sie wachsen mit der Bedrohungslage und deiner IT-Umgebung. Ein Nachmittag für die GPO-Konfiguration, ein Tag für Windows Event Forwarding, und du hast bereits eine Grundlage, die dir bei einem Sicherheitsvorfall unschätzbare Dienste leistet.

Weiterführende Artikel

• Sicherheitsvorfall erkennen und melden: Der komplette Prozess
• Internes ISMS-Audit durchführen: Planung, Checkliste und Bericht
• Active Directory absichern: Die 10 wichtigsten Maßnahmen
• TOMs dokumentieren: Technische und organisatorische Maßnahmen nach DSGVO

Wer seine Logs im Griff hat, kann Vorfälle erkennen, bevor sie eskalieren, kann im Ernstfall nachvollziehen, was passiert ist, und kann gegenüber Auditoren nachweisen, dass die Sorgfaltspflichten ernst genommen werden. Ohne Logging fliegst du blind. Die Entscheidung sollte nicht schwerfallen.